本文我看看Activiti7的架构演变过程，当然目前我们暂时先从整体上看，后续我们也会详细的从源码角度来分析。经过一周的变动之后，我们可以共享项目和存储仓库的新结构。所介绍的变化突出了每个项目的不同性质，以及它们将如何使用和消费。这些变更现在被认为是稳定的，除非我们找到一个新的重组的非常好的理由，这些存储库将被视为Activiti 7项目主要工作的一部分。

在概念上，你会发现有三个主要层，如下图所示:

1.核心层

核心层（core ）将始终包含Java框架，在这种情况下，Activiti/activiti存储库将承载流程引擎，您可以将其嵌入到自己的应用程序中，就像其他任何Java依赖项一样。虽然这对于某些情况来说已经足够了，但它要求您构建一个重要的集成层，并对您的运行时做出一些复杂的决策。我已经看到这样的实现分为如下两类:

将流程引擎嵌入到应用程序:这种方法在应用程序的内存占用、内存消耗和添加过多的责任方面有很大的缺点。

嵌入在服务层中的引擎:这种方法更好，但是它会促使您定义这个服务层。有些公司使用这一层来确保它们不依赖于流程引擎，但这是很昂贵的，需要花很多时间才能把它做好。这个说白了就类似自己包装一个中间件。

上述设计同样适用于查询和审计(Audit )模块，但是我们可能希望在将来的重构中移除这些模块。

2.Service 层

Service 层：我们在Activiti中提供的下一个新层是服务层。正如前面提到的，我们希望避免您必须在引擎的顶部实现这个服务包装器。基于这个原因，我们创建了一个现代的REST HAL  API和基于消息的端点，这些端点可以很容易地扩展和适应您的需要。这些服务是单独设计和实现的，以确保它们遵循单一的职责方法。我们现在提供以下服务:

流程引擎

审计服务

查询服务

这一列表将在未来扩展到更多的服务，并且我们将确保我们的服务不会重叠那些已经由基础设施或者您可能已经使用的其他流行组件提供的功能。在这种情况下，避免重叠的一个典型例子是我们正在使用的新sso/idm组件。我们并没有像大多数BPM引擎那样提供任何家庭成长的sso/idm机制。相反，我们将该职责委托给一个组件，该组件被设计用于为集成层提供SSO和IDM的具体实现。更多的分离组件之间的依赖问题。

3.基础结构层

Infrastructure ：我们的最后一层是基础结构层。我们的新基础架构层允许我们提供一种简单的方式来引导所有这些服务以一种cloud-oriented为导向的方式。我们认识到，我们大多数用户的目标是在现有基础设施上运行这些服务，对我们来说，让他们的生活变得更简单是很重要的。这个基础架构层基于 Spring Boot导、Spring Cloud、Docker和Kubernetes，依赖并重用它们提供的所有服务，从而使我们的服务能够独立伸缩。再一次，通过将我们的服务与这些技术结合起来，我们希望确保我们不会与它们提供的功能重叠。我们希望我们的用户感觉到，当他们采用活动时，他们不需要改变他们的基础设施或者他们在其他服务中做事情的方式。

在Github中，Activiti 创建了几个存储仓库来表示这些层。这些存储仓库在我们的CI服务器中链接，下面的图中箭头表示下游的依赖关系。每次我们在核心引擎中进行更改时，所有的服务都需要重新构建和测试。

还要注意的是，所有依赖于 *-starters的存储仓库都将生成并发布Docker映像到Docker Hub，这意味着您将能够在不需要编译单个Java类的情况下使用所有这些基础设施。这样可以大大降低用户的开发以及学习成本。

要理解的另一件重要的事情是，我们认识到每个实现都可能想要替换一个或多个组件，因此您可以使用示例实现作为引用来实现自己的组件。如果您认为您的一个组件可能会使整个社区受益，那么请联系我们，我们可以帮助彼此进行设计和实现。

4.新方法/新场景

您可能已经注意到，我们现在有了更多的服务、更多的管理、可能的不同类型的存储。显然，使用流程引擎的方式正在发生变化。这种新方法将打开新场景的大门，在这种情况下，我们不会对单个集群流程引擎进行工作。我们希望不同组件发出事件的场景，这些事件将由查询和审计服务等其他组件进行聚合。这些不同的场景可能有不同的需求，例如使用NoSQL数据存储来支持基于图形的数据或json文档进行搜索和索引。这种新方法还将允许我们分别地对基础设施的不同部分进行独立和响应。

正因为如此，我们所有的服务都是经过处理的，并且需要一个编排层来将它们连接起来。下一节将简要介绍这些docker映像，以及如何通过使用Activiti示例来获取所有基础设施和运行。