2.2.2 业务架构设计
应用DDD设计的系统，可以采用传统的分层架构来实现，也可以采用六边形架构和CQRS读写分离架构来实现。
1.分层架构
（1）接口层
统一处理系统对外的服务接口，可以是直接查询，也可以是三方系统对接。
（2）应用层
调用各个领域完成一个具体的业务流程应用，不关心具体的业务实现，例如完成旅客购买机票这个行为，需要旅客和机票两个领域参与。
（3）领域层
实际完成业务逻辑处理的地方，包含领域模型和领域服务，无须关心显示及存储等相关问题。
（4）基础设施层
提供底层支撑功能，包括持久化、序列化与反序列化、消息中间件等。
这种分层架构与我们熟悉的MVC分层架构大同小异，是很容易从传统分层过渡到DDD分层的架构设计。DDD分层架构如图2-5所示。
图2-5 DDD分层架构
2.六边形架构
为六边形架构如图2-6所示。六边形架构可以理解为“去结构化”的架构，系统内部与外界的交互过程通过适配器来完成，没有层次，所有交互双方只知道适配器的存在，不用知晓对方的存在。内部是核心业务逻辑，外部是基础支撑或者其他交互系统。这种架构的好处是显而易见的，一方面是解耦，另一方面是方便外部统一驱动、测试内部程序。例如与REST接口交互，使用REST适配器；与SOAP系统交互，使用SOAP适配器；与消息系统交互，使用消息适配器等。
图2-6 六边形架构
3.CQRS读写分离架构
CQRS读写分离架构如图2-7所示。向左的箭头是Command线，向右的箭头是Query线。
图2-7中为了方便把读写进程画在了一起，读写的数据库也集中在一个数据库。实际上读写完全可以是两套系统，读库和写库也可以完全隔离。读库和写库的同步问题通常采取消息事件机制来解决，也可以监听数据库的binlog类的日志来完成同步。
图2-7 CQRS读写分离架构
实际生产中，笔者推荐将上述三种架构做一个融合，各取所长。架构整体上是六边形架构，去中心化，读写必须分离，最后在各微服务领域内，采用DDD分层结构来组织业务流程及代码。最终架构图如图2-8所示。
图2-8 推荐的架构图
随着业务越来越多元化，越来越复杂，对信息平台的要求也越来越高。系统自然也由简单走向复杂，由单体走向集群。在架构后续的演进中，组件化和服务化几乎就成了一条必经之路。