对组件化架构的再思考

首先对上图做一个解释。原来架构设计比较多关注的是横向的分层，即数据层，逻辑层和UI层。而组件化架构必须同时关注纵向的隔离和解耦。在分层和分模块后，每一个业务组件由三层各自存在的部署包组成，包本身是一个包含了技术组件和服务组件的一个结合体。由数据层，逻辑层，界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件。在业务组件和业务组件之间通过内部ESB进行总线式集成，在业务组件内部的三个业务包仍然通过总线式注册和集成。在组件化架构设计中，需要遵循如下一些原则，这些原则有些属于传统分层架构设计中的原则：

UI层调用逻辑层，逻辑层调用数据层，不应该出现逆向调用。

业务组件间的调用，或说跨模块的调用需要通过服务组件暴露的服务接口进行，跨模块调用建议尽量是同层调用为主，即A模块的逻辑层只能调用B模块的逻辑层，而不能调用B模块的数据层。如果存在对B模块数据层的调用应该转化为B模块的业务服务后暴露到逻辑层。

对于数据库也需要考虑隔离和解耦，为了达到这点，尽量减少对数据库存储过程和关联视图的使用，数据库基本不承载任何的业务规则和逻辑。对数据库中的公用基础数据剥离到公用业务组件中。

对于系统管理，组织，权限，流程等转化为独立的平台层基础组件，为各个业务组件都需要依赖的组件。基础平台层能力如权限，安全，流程，日志等一定要抽取为公用的独立基础组件，业务组件不在承担这部分内容。

不一定要引入复杂的ESB，但是系统内部基于IOC或OSGI模式来实现总线式集成和组件热插拔。

各层提供的服务存在分级，数据层提供数据服务，逻辑层提供业务服务，UI层提供UI组件服务。平台层提供基础的技术服务和流程服务等。

如果在DDD领域驱动架构设计下，数据层转化为基础架构层，业务层转化为领域层，整体思路仍然不变。而领域驱动设计中的应用层转化为组件集成和整合层。

将跨系统的流程整合的概念引入到系统内部，各个业务组件即可以理解为独立的子系统，可以考虑这些子系统间如何通过服务组装和集成解决流程整合的问题，但是并不一定要用到BPEL。

在这种原则下，业务组件之间本身也不存在交叉依赖，业务组件之间的依赖关系是一种多层传递关系，如A组件依赖B组件，B组件依赖C组件。对于整个组件依赖关系建议是一种倒金字塔的结构，这样可以实现最大化的组件独立部署。