微服务与领域驱动设计，架构实践总结( 三 ) _交易

2.4 建模设计
子域和界线上线文完成对业务的拆分切块，从而进行分治；基于防腐层降低各个界限上下文的耦合程度；聚合思想保证了业务问题的解决方案内聚；严格的分层模型实现服务支撑能力的分散；

防腐层(Anticorruption-Layer)：上下文交互时封装的一层；
领域层(Domain-Layer)：在分层架构中负责领域逻辑的设计和实现；
领域服务(Domain-Service)：行为无法识别归属的实体时，封装到领域服务；
聚合(Aggregate)：相关对象的集合，描述核心领域，通常把聚合作为数据修改的单元；
实体(Entity)：通过标识来定义的对象，而不是基于属性，比如Uid标识用户实体；
值对象(Value-Object)：描述特征或属性但没有标识的对象；
工厂(Factory)：封装对象复杂的创建逻辑与类型；
存储库(Repository)：把存储、缓存、搜索等资源封装的机制，对应领域模型；

领域模型的核心追求目标：高内聚、低耦合；更加抽象的、复杂的设计思想，也同样意味着落地实现的难度更高，但不可否认领域模型作为复杂业务的解决方案，逻辑上的确更加合理。
3、工程实践领域模型在代码工程的实践中，可以将不同的子域集成到各自的服务中，也可以在一个服务中，通过多个模块(Module)进行隔离维护，即一个模块对应一个界限上下文；

将业务问题进行分模块分层分包的方式进行隔离，是代码工程中的基本手段，这里只是对组织方式进行描述，在实际的开发中，要根据依赖顺序进行类库拆包管理；
在程序的执行过程中，并不是所有的交互命令都需要经过领域层，实际上大部分业务中的查询命令都是超过增删改命令的，所以在纯读取数据的请求中，应用层可以绕开领域层直接访问基础设施层，减少一层数据处理逻辑。
四、实践总结最后来讨论一些架构实践的经验，随着技术的不断发展和更新换代，为解决业务问题提供了极大的便利，不管是单服务中各种成熟的组件，又或者分布式中的微服务体系，或者聚焦业务管理的领域模型；每种架构选型都有其适用的场景，不同的选型意味着不一样的实现成本；
实际上在做架构选型时，成熟有经验的主导者，都极其擅长做折中处理，也就是常说的退一步海阔天空；通常需要考虑团队的综合水平与业务需求和产品设计，当然在实际的协作流程中多方都是需要相对让步的，但是对质量的要求以及核心业务的实现逻辑上是不能打折的。