从0开发3D引擎（补充）：介绍领域驱动设计

咱们使用领域驱动设计（英文缩写为DDD）的方法来设计引擎，在引擎开发的过程当中，领域模型会不断地演化。
本文介绍本系列使用的领域驱动设计思想的相关概念和知识点，给出了相关的资料。

上一篇博文

从0开发3D引擎（七）：学习Reason语言

下一篇博文

从0开发3D引擎（八）：准备“搭建引擎雏形”

概览

下面的资料粗略地介绍了DDD的相关知识点：
领域驱动设计学习输出
领域驱动设计（DDD）部分核心概念的我的理解

系统学习资料

相关资料为：
DDD理论学习系列

为何用DDD

参考领域驱动设计学习输出:

• DDD 帮助解决微服务拆分困境
• DDD 帮助应对系统复杂性
• DDD 帮助统一语言

相关概念

领域模型

领域模型包括领域服务、实体、值对象

相关资料为：
领域驱动设计之实体、值对象、领域服务
DDD 领域驱动设计学习（五）- 实体/值对象/领域服务

领域模型的分类

可分为四类：

• 失血模型
• 贫血模型
• 充血模型
• 胀血模型

相关资料为：
关于领域模型（贫血模型，充血模型）

架构

DDD主要有分层、六边形、洋葱这几种架构。其中，六边形和洋葱架构都运用了依赖倒置，比较相似。

架构资料：
DDD 领域驱动设计学习（四）- 架构（分层/六边形/RESTful）

分层架构资料：
DDD分层架构的三种模式

洋葱架构资料：
The Onion Architecture

数据

相关概念参考领域驱动设计系列（2）浅析VO、DTO、DO、PO的概念、区别和用处：

　　VO（View Object）：视图对象，用于展现层，它的做用是把某个指定页面（或组件）的全部数据封装起来。
　　DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减小分布式调用的次数，从而提升分布式调用的性能和下降网络负载，但在这里，我泛指用于展现层与服务层之间的数据传输对象。
　　DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
　　PO（Persistent Object）：持久化对象，它跟持久层（一般是关系型数据库）的数据结构造成一一对应的映射关系，若是持久层是关系型数据库，那么，数据表中的每一个字段（或若干个）就对应PO的一个（或若干个）属性。

相关资料为：
领域驱动设计系列（2）浅析VO、DTO、DO、PO的概念、区别和用处

　　

通用语言，又叫统一语言

相关资料为：
DDD 领域驱动设计学习（一）- 领域模型和统一语言
重读领域驱动设计——如何说好一门通用语言

事件风暴

咱们使用事件风暴做为DDD的开始，获得通用语言。

相关资料为：
领域驱动设计: 服务边界划分
使用事件风暴探索业务全景

领域和子域

相关资料为：
DDD理论学习系列（2）-- 领域

限界上下文

相关资料为：
DDD理论学习系列（3）-- 限界上下文

上下文映射图

参考DDD—上下文映射图，上下文之间有下面的关系：

• 合做关系（PS）：若是两个限界上下文的团队要么一块儿成功，要么一块儿失败，此时他们须要创建起一种合做关系。他们须要协调开发计划和集成管理。
• 共享内核（SK）：对模型和代码的共享将产生一种紧密的依赖性，对于设计来讲，这种依赖性可好可坏。咱们须要为共享的部分模型指定一个显式的边界，并保持共享内核的小型化。共享内核具备特殊的状态，在没有与另外一个团队协商的状况下，这种状态是不能改变的。咱们应该引入一种持续集成过程来保证共享内核与通用语言的一致性。
• 客户方——供应方开发（CSD）：当两个团队处于一种上游-下游关系时，上游团队可能独立于下游团队完成开发，此时下游团队开发可能会受到影响。所以，在上游团队的计划中，咱们应该顾及到下游团队的需求。
• 遵奉者（C）：在存在上游-下游关系时，若是上游团队已经没有动力提供下游团队之所需，下游团队便孤军无助了。只能盲目地使用上游团队的模型。
• 防腐层（ACL）：在集成两个良好的限界上下文时，翻译层可能很简单，甚至能够很优雅地实现。可是，当共享内核、合做关系或客户方-供应方关系没法顺利实现时，此时的翻译将变得复杂。对于下游客户来讲，你须要根据本身的领域模型建立一个单独的层，该层做为上游系统的委派向你的系统提供功能。防腐层经过已有的接口与其余系统交互，而其余系统只须要作很小的修改，甚至无须修改。在防腐层内部，它在你本身的模型和他方模型之间进行翻译转化。
• 开放主机服务（OHS）：定义一种协议，让你的子系统经过该协议来访问你的服务。你须要将该协议公开，这样任何与你集成的人均可以使用该协议。在有新的集成需求时，你应该对协议进行改进或者扩展。对于一些特殊的需求，你能够采用一次性的翻译予以处理，这样能够保持协议的简单性和连贯性。
• 发布语言（PL）：在两个限界上下文之间翻译模型须要一种公用的语言。此时你应该使用一种发布出来的共享语言来完成集成交流。发布语言一般与开放主机一块儿使用。
• 另谋他路（S）：在肯定需求时，咱们应该作到坚持到底。若是两套功能没有显著的关系，那么它们也能够被彻底解耦的。声明两个限界上下文之间不存在任何关系，这样使得开发者去寻找简单的、专门的方法来解决问题。

相关资料为：
看看上下文映射的清晰视图
DDD—上下文映射图

聚合

聚合Aggregate就是一组相关对象的集合，咱们把它做为数据修改和访问的单元。一个聚合包含聚合根、实体和值对象。

相关资料为：
领域模型：聚合、聚合根
领域驱动设计-聚合

在UML中，须要区分聚合关系和组合关系，详见：
浅谈UML中的聚合与组合

服务

服务包括应用服务、领域服务、基础服务。

基础服务是指基础设施中提供的服务，一般用于操做外部，如发送email等。

应用服务和领域服务的相关资料为：
如何分辨应用服务与领域服务
领域驱动设计DDD之领域服务

仓库

咱们使用仓库来操做PO。

相关资料为：
DDD理论学习系列（12）-- 仓储

DDD应用示例

相关示例为：
领域驱动设计在互联网业务开发中的实践
基于 DDD 的微服务设计和开发实战