层的划分
领域建模中的分层架构
传统企业应用大多是单体架构，而单体架构则大多是三层架构。三层架构解决了程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念，在物理上它是中心化的集中式架构，并不适合分布式微服务架构。DDD 分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界；DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。
三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。
- DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
- 另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。
在最早的传统 DDD 四层架构中，基础层是被其它层依赖的，它位于最核心的位置，那按照分层架构的思想，它应该就是核心，但实际上领域层才是软件的核心，所以这种依赖是有问题的。后来我们采用了依赖倒置（Dependency inversion principle,DIP）的设计，优化了传统的四层架构，实现了各层对基础层的解耦。
在微服务架构模型比较常用的有几个，例如：整洁架构，CQRS（命令查询分离）以及六边形架构。每种架构模型都有自己的应用场景，但其核心都是“高内聚低耦合”原则。而运用领域驱动设计（DDD）理念以应对日常加速的业务变化对架构的影响，架构的边界越来越清晰，各司其职，这也符合微服务架构的设计思想。以领域驱动设计（DDD）为理念的分层架构已经成为微服务架构实践的最佳实践方法。
- 展现层
展现层负责向用户显示信息和解释用户指令，常表示客户侧相关应用。
- 用户接口层
用户接口层面向用户访问的数据入向接口，可按不同场景提供不一样的用户接口实现，这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。面向 Web 的可使用 HTTP RESTful 的方式提供服务；面向微服务的可使用 RPC 方式提供服务，可增加限流、熔断等功能。
- 应用层
应用层是尽量简单的很薄的一层，它不包含业务规则或知识，只为下一层的领域对象协调任务，协调和指挥领域对象来完成业务逻辑，是与其他系统的应用层进行交互的必要渠道。应用层位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。
此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。还有，应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。需要注意的是，在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。
- 领域层
领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型。需要注意的是，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。其次，你要知道，实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
- 基础层
基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
比如说，在传统架构设计中，由于上层应用对数据库的强耦合，很多公司在架构演进中最担忧的可能就是换数据库了，因为一旦更换数据库，就可能需要重写大部分的代码，这对应用来说是致命的。那采用依赖倒置的设计以后，应用层就可以通过解耦来保持独立的核心业务逻辑。当数据库变更时，我们只需要更换数据库基础服务就可以了，这样就将资源变更对应用的影响降到了最低。
COLA
COLA 的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分成应用层、领域层和基础实施层。如下图所示，左边是传统的分层架构，右边是 COLA 的分层架构。
其每一层的作用范围和含义如下：
- 展现层（Presentation Layer）：负责以 Rest 的格式接受 Web 请求，然后将请求路由给 Application 层执行，并返回视图模型（View Model），其载体通常是 DTO（Data Transfer Object）；
- 应用层（Application Layer）：主要负责获取输入，组装上下文，做输入校验，调用领域层做业务处理，如果需要的话，发送消息通知。当然，层次是开放的，若有需要，应用层也可以直接访问基础实施层；
- 领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Entities）的函数对外部提供业务逻辑的计算和处理；
- 基础实施层（Infrastructure Layer）主要包含 Tunnel（数据通道）、Config 和 Common。这里我们使用 Tunnel 这个概念来对所有的数据来源进行抽象，这些数据来源可以是数据库（MySQL，NoSql）、搜索引擎、文件系统、也可以是 SOA 服务等；Config 负责应用的配置；Common 是通用的工具类。
六边形架构
六边形架构主打的是内外分离，体现业务逻辑的应用层与领域层处于六边形架构的内核，并通过内部的六边形边界与基础设施的模块隔离开。当我们在进行软件开发时，只要恪守架构上的六边形边界，则不会让技术实现的复杂度污染到业务逻辑，保证了领域的整洁。边界还隔离了变化产生的影响。如果我们在领域层或应用层抽象了技术实现的接口，再通过依赖注入将控制的方向倒转，业务内核就会变得更加的稳定，不会因为技术选型或其他决策的变化而导致领域代码的修改。
领域服务
有些领域中的动作，它们是一些动词，看上去却不属于任何对象。它们代表了领域中的一个重要的行为，所以不能忽略它们或者简单地把它们合并到某个实体或者值对象中。当这样的行为从领域中被识别出来时，最佳实践是将它声明成一个服务。这样的对象不再拥有内置的状态。它的作用仅仅是为领域提供相应的功能。Service 往往是以一个活动来命名，而不是 Entity 来命名。
例如转账的例子，转账（transfer）这个行为是一个非常重要的领域概念，但是它是发生在两个账号之间的，归属于账号 Entity 并不合适，因为一个账号 Entity 没有必要去关联他需要转账的账号 Entity，这种情况下，使用 MoneyTransferDomainService 就比较合适了。识别领域服务，主要看它是否满足以下三个特征：
- 服务执行的操作代表了一个领域概念，这个领域概念无法自然地隶属于一个实体或者值对象。
- 被执行的操作涉及到领域中的其他的对象。
- 操作是无状态的。
在使用领域服务时要特别当心，一个比较常见的错误是没有努力为行为找到一个适当的对象，就直接抽象成领域服务，这会使我们的代码逐渐转化为过程式的编程，一个极端的例子是把所有的行为都放到领域服务中，而领域模型退化成只有属性的贫血 DO，那 DDD 就没有任何意义了。所以一定要深入思考，既不能勉强将行为放到不符合对象定义的对象中，破坏对象的内聚性，使其语义变得模糊。也不能不加思考的都放到领域服务中，从而退化成面向过程的编程。
决定一个服务（Service）应该归属于哪一层是很困难的。如果所执行的操作概念上属于应用层，那么服务就应该放到这个层。如果操作是关于领域对象的，而且确实是与领域有关的、为领域的需要服务，那么它就应该属于领域层。总的来说，涉及到重要领域概念的行为应该放在 Domain 层，而其它非领域逻辑的技术代码放在 App 层，例如参数的解析，上下文的组装，调用领域服务，消息发送等。还是银行转账的 case 为例，下图给出了划分的建议：