结合领域驱动设计、查询命令分离的SOA分布式无共享架构

结合领域驱动设计、查询命令分离的SOA分布式架无共享构
一、SOA、DDD、CQRS、DCI的定义
SOA（面向服务架构）是一种分布式的软件架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行部署、组合和使用。简单来说，SOA就是一种大型 系统开发的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口的组件（也就是service）组合构建起来的，它是 针对多核心多平台之间的数据交换。

DDD（领域驱动设计）它的核心内容是“如何将业务领域概念映射到软件工程当中”。它推翻了“软件从数据层开发设计”的旧习惯，强调领域模型在软件中发挥的强大力量，注重如何把企业内部复杂的业务流程转化为软件。

CQRS(命令查询的责任分离)Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式，能够使改变模型的状态的命令和模型状态的查询实现分离。

DCI(数据场景行为)是对象的Data数据, 对象使用的Context场景, 对象的Interaction交互行为三者简称， DCI是一种特别关注行为的模式(可以对应GoF行为模式)，而MVC模式是一种结构性模式，DCI可以使用演员场景表演来解释，某个实体在某个场景中扮演包公，实施包公升堂行为

二、SOA、DDD、CQRS、DCI的结合
1、SOA+DDD结合
服务导向的架构可以被认为是一种演化，而不是革命。它捕捉到了之前体系架构的许多最佳实践或实际应用。比如在通信系统中，近年来进展有限的解决方案多采用 完全静态的绑定来与网络中的其他设备沟通，但若正式采用SOA方式，解决方案就更能妥善定位，进而突显定义明确且可高度跨平台操作接口的重要性SOA针对的是大型系统的总体架构，注重如何把系统进行项目分离，隔离开发，最后实现系统合并。而DDD是针对单个项目的开发管理过 程，注重如何利用领域模型把业务需求转化为软件。两者之间并没有存在理论上的冲突，能把两者结合，各展所长，更能发挥各自的优势。

2、DDD、CQRS、DCI结合

(1) DDD+CQRS
不要认为领域模型可以做任何事情，比如查询。领域模型只能帮你处理业务逻辑，你不要用它来帮你做查询的工作，那不是它擅长的领地，因为它的存在目的不是为了查询；CQRS的思想就是指导我们：命令和查询因该完全分离，领域模型适合处理命令的部分，而查询可以用其他任何的不依赖于领域模型的技术来实现，甚至可以直接写SQL也可以；
很多应用都需要持久层保存状态，因为这些状态不能丢失，如果只是放在内存中，而不是持久到磁盘上。状态是在领域模型中，每当模型保存到数据库以后，会有更多复杂的查询，都是使用复杂且慢的SQL语句实现的，在客户端就将数据的新增修改删除等动作和查询进行分离，前者称为Command，走Command bus进入Domain对模型进行操作，而查询则从另外一条路径直接对数据进行操作，比如报表输出等。
CQRS和关系数据库的读写分离策略也是相似的，查询是读，而状态修改一般是写，CQRS允许我们为查询优化数据表结构，因为对象领域模型的存储，数据表结构是无所谓的，但是如果你使用Hibernate/JPA等ORM框架，就很难实现为查询优化数据表结构，因为ORM框架绑定领域模型和数据表。
 

当一个Command进来时，从仓储Repository加载一个聚合aggregate对象群，然后执行其方法和行为。这样，会激发聚合对象群产生一个事 件，这个事件可以分发给仓储Repository，或者分发给Event Bus事件总线，比如JavaEE的消息总线等等。事件总线将再次激活所有监听本事件的处理者。当然一些处理者会执行其他聚合对象群的操作，包括数据库的 更新。
因为领域对象操作和数据库保存持久这两个动作分离，因此，数据表结构可以和领域对象松耦合，你可以优化数据表结构专门用于查询。

再者，由于事件驱动了领域模型的状态改变，如果你记录这些事件audit ，将可以将一些用户操作进行回放，从而找到重要状态改变的轨迹，而不是单纯只能依靠数据表字段显示当前状态，至于这些当前状态怎么来的，你无法得知。当你 从数据库中获得聚合体时，可以将相关的事件也取出来，这些叫Event Sourcing，事件源虽然没有何时何地发生，但是可以清楚说明用户操作的意图。

虽然这种架构有些复杂，但是好处却很多，主要的是实现 透明的分布式处理Transparent distributed processing，当使用事件作为状态改变的引擎时，你可以通过实现多任务并发处理，比如通过JVM并行计算或事件消息总线机制，事件能够很容易序列 化，并在多个服务器之间传送，(EJB提倡贫血失血模型，实际就是为解决胖模型在多个服务器之间传送时序列化耗费性能，现在我们不序列化模型，而是改变模 型数据的事件)。

(2) DDD+DCI
DDD告诉对象“是什么”，却不能很自然的解决“做什么;
DDD的在对象设计方面的最大贡献之处在于其实体、值对象，以及聚合边界的三个部分，通过这三个概念，我们可以将对象的静态结构设计好
碰到一个业务系统，我们该如何分析业务，分析需求，并最后得到一个只包含业务概念的模型？答案是通过四色原型进行业务建模。四色原型的中心思想是：一个什么什么样的人或组织或物品或地点以某种角色在某个时刻或某段时间内参与某个活动。 其中“什么什么样的”就是DESC，“人或组织或物品或地点”就是PPT，“角色”就是Role，而”某个时刻或某段时间内的某个活动"就是MI。
业务模型建好了，该如何通过面向对象的分析与设计方法来进行对象建模呢？ DDD和DCI思想可以帮助我们。首先，DDD能够指导我们建立一个静态的领域模型，该领域模型能够清楚的告诉我们建立出来的对象“是什么”，但是DDD却不能很自然的解决“做什么”的问题。大家都知道DDD在对象设计的部分实际上是一种充血模型的方式，它强调对象不仅有属性还会有行为，如果行为是跨多个领域对象的，则在DDD中用领域服务解决。但是DDD却没有完整的考虑对象与对象之间的交互如何完成，虽然它通过领域服务的方式协调多个对象之间进行交互或者在应用层协调多个对象进行交互。但是在DDD中，对象往往会拥有很多不该拥有的属性或行为。
以下是DCI的核心思想：
对象扮演某个角色进入场景，然后在场景中进行交互，场景的参与者就是对象所扮演的角色；
一个对象可以扮演多个角色，一个角色也可以被多个对象扮演；
对象的属性和行为分为：A：核心属性和行为，这些属性或行为是不依赖于任何场景的；B: 场景属性和行为，对象通过扮演某个角色进入某个特定场景时拥有的属性或行为，一旦对象离开了这个场景，不再扮演了这个角色后，这些场景属性或行为也就不再属于该对象了；比如人有核心的属性和行为：身高、体重、吃饭、睡觉，然后当人扮演教师的角色在教室里上课时，他则具有上课的行为，一旦回到家里，就又变成了一个普通的人；比如一个物品，在生产时叫产品，在销售时叫商品，坏了的时候叫废品，它在不同阶段扮演不同的角色所具有的属性是不一样的；
场景的生命周期，场景是一个时间与空间的结合，可以理解为某个活动；一旦活动结束，则场景也就消失；
DCI中的D可以理解为DDD中的领域模型；场景中交互的是角色，而不是领域实体。场景属于DSL的思考层面，更接近于需求和用例。而领域也是伟大的出现，但是不能为了领域而领域，为什么呢？因为场景是大哥用例是大哥。领域的存在是为了控制固定概念的部分，这样在某种成度上控制了一定的复杂性和提高了可控性，而DCI则解决了可变性和需求的问题。从某种意义上来说，“领域层（在DCI中可能不会太凸显领域层，不如OLD DDD那么凸显）” 是为了DCI架构服务的。
角色是人类的主观意识，用于对象分析和设计阶段，但是在运行阶段，角色和对象实体是一体的，软件运行过程中只有对象，只是这些对象在参与某个活动时扮演了某个角色而已；

三、DDD的分层结构
Presentation Layer(表现层)
表现层负责提供用户的接口，它和传统的表现层的概念是一致的。表现层仅仅是负责接受用户的请求，然后调用应用层层获取领域对象来渲染结果视图，最终进行视图的展现。表现层主要采用MVC模式。
Application Layer (应用层)
应用层定义了软件系统所能做的事情，但是它不负责怎么做，也就是说应用层只定义了"what to do",而不关注"How to do".应用层负责调用具有丰富业务逻辑的领域对象来完成某一次的业务操作。同时应用层还需要负责提供与其它系统进行交互的接口。
应用层不负责保存与业务有关系的状态，它仅仅只是将工作委托给领域对象来完成，虽然应用层不包含业务规则和状态，但是应用层可以包含操作过程的状态，比如事务状态等。
Domain or Model Layer(领域或模型层)
领域层是系统的核心，领域层实现了软件的核心的业务逻辑和业务规则，领域模型就属于这一层。
领域层具体会包括很多重要的对象，这部分将在“领域驱动设计中的关键角色”部分说明。
Infrastructure Layer(基础结构层)
Infrastructure Layer提供了系统技术性的支持，比如持久化访问数据库，消息发送，邮件发送等。

 

四、细说Repository
 首先必须说明的是Repository数据仓储接口属于领域层，Repository数据仓储的实现属于基础设施层的；
基础设施层是你写的基础设施代码，而不是现存的第三方类库和框架，例如hibernate之类
jms, jmail等，地位和Hibernate都是平等的，都是用于实现基础设施层的工具
 另外就是，门面层（应用层）和领域层都可以使用基础设施层来实现功能。代码中，领域层没有使用基础设施层。如果这样的话，领域层就会非常贫血了。  通过控制反转，保证基础设施层依赖于领域层，而不是相反（通过把基础设施层的接口放在领域层中来实现）。以达到系统可以切换不同基础设施层的目的

 

 
五：细说应用层
 在开发SOA分布式系统的时候，应用层是一个重点，它主要有两个作用。
第一，应用层主要作用是协调领域层工作，指挥领域对象解决业务问题，但应用层本身不会牵扯到业务状态。
第二，在SOA系统当中应用层是数据运输中心和信息发放的端口，担负着数据转换与数据收发的责任。
它有以下的特点：
粗粒度
分布式系统与普通网站和应用程序不同，因为它假定外界对系统内部是毫无了解的，用户只想输入相关数据，最后得到一系列计算结果。所以我们应该把计算结果封装在一个数据传输对象（DTO）内，实现粗粒度的传递，这是一般项目与SOA系统在服务层的一个最明显的差别。 想想如果一个页面需要同时显示一个顾客的个人资料、某张订单的详细资料，那将要同时获取Person、Order、OrderItem三张表的信息。在普 通系统的开发过程中，这并不会造成太大问题，但在使用远程服务的时候，如果用三个方法分别获取，那将会造成不少的性能损耗。特别是在分布式开发系统中，应 用层与表现层之间是实现分离的，更多时候两者是由不同部门所开发的模块，表现层不会了解应用层中的逻辑关 系，Person，Order，OrderItem三样东西在表现层看来，也就是同一样东西，那就是返回值。所以在系统内，应该把多张表的信息封装在一个 DTO对象内，通过应用层一个远程方法一次性返还。使用粗粒度的数据元素是分布式系统的一个特点。
传输性
如果你熟悉SOA系统，对DTO（Data Transfer Object 数据传输对象）这个词一定并不陌生。DTO属于一个数据传输的载体，内部并不存在任何业务逻辑，通过DTO可以把内部的领域对象与外界隔离。DTO所封装 的是客户端的数据，所以它的设计更多地是针对客户端的需求，而不是业务逻辑。比如说本来Person与Order是一对多的关系，但当一个页面只要显示的 是一个客户的单张订单信息，那我们就可以根据需要把DTO中的Person和Order设计为一对一的关系。如果你是使用MVC开发一般的网站，更多时候 会把返回对象直接转化为Model。如果你开发是一个分布式系统，那更多时候会从系统性能与隐藏业务逻辑出发着想。而且考虑到把内部对象转化为DTO，将 是一件麻烦的事，建议应该考虑DTO的兼容性，使DTO可以作为多个方法的返还载体。（注意：在SOA系统内，应该从性能出发优先考虑粗粒度元素的传输性 问题）
封装性
在SOA系统当中应用层服务的发布并不需要复杂的模型，只需使用外观模式（Facade）把一些功能封装在少数的几个服务类里面，使用Web Service、TCP/IP套接字、MSMQ等服务方式向外界发布。
在开发SOA系统的时候，应用层的服务需要使用远程方法对外开放，在接收到请求的时候，它可以调用领域层服务获取运算结果，然后通过数据转换器 OperationAssembler把运算结果转换成DTO，最后返还到表现层。在起初，我曾尝试对应每个应用层的对象建立一个远程接口，但经过多次重 构以后，我觉得行程对象就是一个简单的对外接口，对象之间不存在什么逻辑关系。所以更简单的方法是使用外观模式，建立少数的几个远程服务类，把所有的应用 层对象的方法都包含在内。
六、系统总体架构
到此总结一下领域驱动设计DDD的总体结构，Repository层使用ORM映射或SQL命令等方式把持久化数据转化为领域对象，然后根据业务逻 辑设计对应领域层服务Domain Service 。接着应用层进行操作上的协调，利用Repository、领域模型、领域层服务Domain Service 、场景服务组件、统一查询组件完成业务需要，再通过数据转换器把领域对象Domain Object转化为数据传输对象DTO。最后，利用远程通讯技术把应用层的服务（Application Service）对外开放。

参考秋水逍遥、板桥、风尘浪子、狂放不羁、aoyo等架构思想
作者：两栖狼 QQ：46580583