【往期回顾】
前几篇已经将领域驱动设计的核心部分，领域（Domain）做了详细的介绍。如果没有看的同学可以先做一下预习。
老生常谈：
领域驱动设计(DDD) 是一个软件开发的方法论，旨在解决复杂软件的的设计与构建的问题。通过建立通用语言，在业务与技术之间进行准确的沟通，消除歧义。最终一起构建一个准确反映业务的领域模型，来确保软件能准确的反映复杂的业务逻辑。
【划重点】: 领域模型是业务模型的准确反映，是业务与技术之间沟通的桥梁，也是业务与技术的共识。
因此领域模型必须得到很好的保护，他的变更只能有业务的变更而引起，不能因内部软件设计和外部的调用来改变领域模型。
对内，领域就像一只完整建制的团队
用日常工作中大家熟悉的研发团队来做个类比，用以说明领域层各概念的作用：
领域层：理解为一个独立的项目研发团队，团队由不同角色岗位组成，团队的组建是为了完成某一项目（业务需求）；
领域模型：团队中岗位角色（产品岗、研发岗、测试开发岗等），一个团队由一种或多种岗位角色组成（一个或多个领域模型），每个岗位角色都定义了其工作职责内容（领域模型需要实现的业务能力）；
界限上下文：定义团队内每个岗位角色的职责边界；
实体：某一岗位内的成员，一个或多个组成，可根据大家优势（实体的属性和方法），进行不同的分工，一起协作（聚合）完成一件工作（业务能力）。
值对象：岗位基础能力，每个对应岗位成员应具备的能力，根据工作需要可以使用这个能力（实体属性可包含这个值对象），不具备独立性。
聚合根：某一岗位的leader（如：产品岗的leader），负责与团队内其他岗位（如：PM）沟通、协调。
领域服务：可以理解为PM或团队leader的角色，协调各岗位边界外的事情（可以调用多个聚合根组合成一个业务场景能力，对外提供服务），比如：与其他团队沟通（多个聚合根），接收需求指令（外界下达的指令），下达指令（调用不同聚合根）、向上汇报（返回指令结果）等。
领域事件：当有重大变更或重大行为涉及到其他团队时（扣减库存、增加资产等），可由PM或团队leader的角色（领域服务）发布信息（发布-订阅模式），通知相关干系人（如：库存域，扣减库存）。
工厂：由PM或团队leader的角色（领域服务），提出团队岗位资源（创建实体对象）的诉求，由工厂（资源池）提供合适的团队成员（实体）。
团队的建立是需要根据项目的需求（业务需求）来确定，建设多少个团队（领域拆分），每个团队由什么角色（领域模型）组成，每个团队要完成的工作（业务能力）等在项目启动时，已经明确定义。
在实施过程中，我们必须按照岗位角色（领域模型）定义好的职责边界（界限上下文）和岗位职责（领域模型需要实现的业务能力）合理利用好每位成员（实体），各岗位严格按照定义的岗位职责做好本职工作（领域模型只输出与自己相关的业务能力），岗位成员不能跨岗互相轮换（不同领域模型中的实体不能互相引用），同一岗位内部的成员可以根据需要自由组合完成一项工作（领域模型内部的实体，可以根据业务需要自由聚合）。
在一个项目团队（领域）中，岗位之间的沟通协作由岗位leader（聚合根）负责，对外由PM或团队leader（领域服务）负责。
如果涉及其他项目团队（其他领域），由PM或团队Leader（领域服务）负责下发信息（领域事件）。
对外构建防腐层隔离领域模型被侵蚀
非DDD模式下：
我：阿三，把你的左手借我用一下，我用你左手喂小孩吃饭。
阿三：给你我的左手。
你接过阿三给你的左手按在你自己身上，用这只借来的手开始喂小孩吃饭。
DDD模式下:
我：我想吃饭，阿三。
阿三接收到你的信息（指令）后，用自己的左手，喂小孩吃饭。然后把吃饭的结果反馈给你。
在DDD模式下，领域层通过领域服务，接收到下达的指令，领域层内部根据指令完成任务，并将结果返回给指令方。
领域服务就像一座城城墙，保护着城内的百姓（领域模型、对象等），对外连接是一座座城门（API），城门开关、允许什么样的人（对象）进城，都有领域自己决定，这座城墙保护者城内的一切不受外界干扰。
最后
至此，对于领域驱动设计（DDD）中的领域（Domain）以全部讲解完毕，后续将持续讲解应用层、基础设施层、展现层。
