显卡|微服务与领域驱动设计，架构实践总结( 三 ) 游戏主机|机箱|雷神|数码

2.2 界限上下文
DDD中最晦涩难懂的一个抽象概念，特定模型的限界应用，不过可以借用原文的比喻会意一下：细胞之所以能够存在，是因为细胞膜限定了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜：

界限上下文的定义涉及粒度的思想，即每个粒度要具备独立性；如上图仓储业务，可以将服务部署与仓储子域、仓储上下文做成一一对应的关系，或者在仓储子域中分别定义：仓库和货架两个上下文；这里具有极大的灵活性，没有真正意义上的标准可以参考。
2.3 映射关系
做好界限上下文的划分，理清各个上下文之间的关系，明确业务场景中的依赖顺序，这样可以更好地推动开发流程的落地；对于上下文的关系描述也远不止图中的这些，还有共享内核、合作等等:

上下游(U-上游， D下游)：描述上下文调用时的关系，服务调用方为D ，服务提供方为U；
防腐层(Anticorruption-Layer ，简写ACL)：上下文交互时封装的一层，提供对动作的校验、适配、转换等；
开放主机服务，发布语言(Open-Host-Service简写OHS ， Published-Language简写PL)：定义访问协议；

在上下文交互时，防腐层可以维护上下文的隔离和独立，确保调用方不直接依赖服务提供方，从而实现不同上下文之间的依赖解耦；同时这也会带来大量的对象转换动作；
2.4 建模设计
子域和界线上线文完成对业务的拆分切块，从而进行分治；基于防腐层降低各个界限上下文的耦合程度；聚合思想保证了业务问题的解决方案内聚；严格的分层模型实现服务支撑能力的分散；

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

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

将业务问题进行分模块分层分包的方式进行隔离，是代码工程中的基本手段，这里只是对组织方式进行描述，在实际的开发中，要根据依赖顺序进行类库拆包管理；
在程序的执行过程中，并不是所有的交互命令都需要经过领域层，实际上大部分业务中的查询命令都是超过增删改命令的，所以在纯读取数据的请求中，应用层可以绕开领域层直接访问基础设施层，减少一层数据处理逻辑。
四、实践总结最后来讨论一些架构实践的经验，随着技术的不断发展和更新换代，为解决业务问题提供了极大的便利，不管是单服务中各种成熟的组件，又或者分布式中的微服务体系，或者聚焦业务管理的领域模型；每种架构选型都有其适用的场景，不同的选型意味着不一样的实现成本；