领域驱动设计的提出也是为了解决软件的复杂性。软件的核心功能就是解决现实的领域问题，通过建模，然后通过软件实现，完成领域问题的自动化。二软件不同于其他行业的主要问题是软件面对的领域问题是千差万别的，所以很难形成标准的模型来解决。因此DDD（领域驱动设计）的核心就是关注领域知识，通过对领域知识的理解，抽象，建模，实现，最终完成软件的设计。而不是关注软件实现技术，架构。就想提到设计模式的时候说的一句话，设计模式是自然而然的出现在了你的设计中，而不是为了使用而使用。其本质也是这个意思，当你对你的问题能很好的抽象建模后，再按照面向对象的设计原则，通过面向对象的抽象，继承，封装的技术，那么自然而然的就呈现出了设计模式的形式。所以领域驱动设计的第一步就是要和领域专家沟通，熟悉领域知识。所以第一步就是把领域知识通过图，用例，画等方式模型化，建立通用语言，通过模型和领域专家交流，这些最终到了设计阶段，也就是团队内部的通用语言和对象，服务等的命名。

模型和架构：
在领域驱动设计这本书中讲了分层架构，从上到下分成四层，UI层，application层，Domain层，Infrastructure层，从上到下，上层可以依赖下层，但是下层不能依赖上层，其目的还是要做到Domain层和Infrastructure和UI层的分离，这样可以单独针对业务层建模，方便测试，维护。而应用层是很薄的一层，用来协调应用的活动，不包含业务逻辑，通过调用领域层来完成一些业务流程。所以从这个划分来看，Clear架构，六边形架构更能反应这个思想。

模型驱动设计：

图片发自简书App

Entities 实体，在整个系统的生命周期中都有唯一标识的对象，比如订单，账户，等对象。系统需要给这种对象生成一个我唯一的ID，所以这些对象需要持久化，需要保存到repository中。

value object 值对象，用来描述领域的特殊方面，且没有标识符的一个对象。值对象不像实体对象，值对象是可以创建，销毁，复制，是需要依赖于实体对象。比如地址。值对象的不变性，是值对象的一个重要特性，就是说一个值对象创建以后就不能改变了。所以值对象一般只包含无副作函数，如果要改变值对象，就重新生成一个，如果要获取一个值对象，就返回一个clone的对象。这样可以有效的避免了在聚合外部对值对象的修改造成值对象的改变。避免了模型内部的相互影响。

service 服务，是对领域中的一些行为的抽象，不同于技术框架中的服务。领域建模中，领域语言的名词很容变成实体或值对象，一些动词可以变成实体和值对象的行为。但是一些行为很难附属于对象。对于这种就可以定义为服务。服务的几个特征：1.服务之星的操作涉及一个领域概念，这个领域概念通常不属于一个实体或值对象。2.被执行的操作涉及到领域中的其他的对象。3.操作是无状态的。

aggregates 聚合，聚合是用来定义对象所有权和边界的领域模式，聚合是针对数据变化可以考虑成一个单元的一组相关的对象，对外只暴露聚合根，聚合根是一个实体，如果边界内有其他的实体，那么实体的标识符是本地化的，只在聚合内有意义。因为聚合只有根对外暴露，所以很容通过聚合保持数据的一致性和强化不变量。不变量是指在数据发生变化时必须维护的那些规则，通常数据库中会遇到这些问题。聚合内的其他对象都是通过从聚合根的导航获取到的。

factory 工厂，工厂不是一个领域概念，是一个设计上的概念，是用来辅助领域对象创建复杂的对象，把创建对象的复杂过程封装起来。具体实现可以参考设计模式的工厂模式。

repository 资源库，资源库的目的是封装所有获取对象饮用所需要的逻辑，资源库是作为一个全局的可访问对象的存储点而存在。解耦领域对象和基础设施。repository长和常用的ORM结合起来使用。

保持模型的一致性 — 在实现领域驱动设计那本书里面叫战略设计

图片发自简书App

这部分主要解决大项目，需要多个团队协作的情况下如何保证模型的一致性，多个团队协作的时候，信息的沟通传递成了最大的挑战，随着项目的深入，对领域知识的理解也会更深入，或者新的需求的引入，原有的模型也可能需要重构。这也是软件工程一直以来的一个挑战。比如一个类，在不同的场景或者业务中需要增加，删除一些属性，如果在夸团队协作时就回来带很多不一致的问题。所以讲大的模型分解成几个较小的独立部分，只要遵守相互绑定的契约，整合的好的小模型就会越来越独立。这也是DDD被越来越多的和微服务结合起来的原因。

context 限界上下文，模型的上下文是一个条件集合，用这些条件可以确保应用在模型里的条款都有一个明确的含义。怎么理解呢，比如我们听一句话的意思可能要放到上下文环境里面去理解，那么在领域建模的时候也是同样，一个概念在不同的上下文中表达的意思，属性是有些差别，比如某一个产品在现实给用户的购买页面和在库存管理两个不同的上下文就有不同的属性。或者一个用户在身份认证上下文和购物上下文中就有不同，身份认证更关注用户的权限类型，密码。而购物上下文更关注的是什么等级，是不是金牌用户。所以通过对上下文的划分形成独立的限界区域，由一个团队来负责一个限界上下文，因为团队内部可以保证充分的沟通，一个概念只需要在一个限界上下文中保持一致即可。在一个限界上下文中有一个统一语言，用来在团队内部沟通。限界上下文之间通过良好的接口设计来协作。

context Map，是指抽象出不同限界上下文和他们之间关系的文档，可以是一个示图。目的是让每个在项目中工作的人都能看到并理解。可以考虑放到公共的区域，比如墙上，白板上。

图片发自简书App

子系统之间的关系：
共享内核 是指两个团队统一共享的领域模型子集，共享内核的目的是为了减少重复，但是两个团队维护，所以要做到团队之间密切的交流，任何修改都要通知对方团队，而且要做到尽快的融合代码。
客户供应商关系， 两个子系统，一个依赖另外一个。

防崩溃层，在需要和一流软件或其他独立应用集成时可以借用设计模式的facade和adapter模式来设计一个防腐层。