领域驱动设计整理——概念&架构

领域、子域、限界上下文

DDD（Domain-Drive Design）的概念或者说业界的声音其实可以追溯到几十年前了。最近开始想要系统得整理一下DDD的一些东西。这一篇是一个简单的引子，也是mark一下自己接触到的概念和理解。
对于领域的概念其实很好理解，就如字面意思一样，比如出版书籍领域，广告设计领域。圈定了一定的范畴，并且在这个范畴内，所有团队成员对于某一概念的理解是一致的。比如书籍就是我们需要出版的书籍，而不是比如出版社给员工提供的什么季度奖励书籍。也许这里的例子还是有点偏差，但是当具体设计系统的时候就会去思考真正的业务边界。
我理解的领域驱动设计不是一种设计风格，也不是一种架构模型。而是一种思考方式。在考虑一个项目、需求的时候不会先去思考需要怎样的数据存储结构以及会有哪些行为和操作需要实现。而是去思考业务中一些重要的核心界限以及概念。最重要的就是定义通用语言。如何定义一个限界上下文的通用语言，来保证在具体的系统设计中，也即一个限界上下文中是一个唯一概念是非常重要的。限界上下文包含了模块（领域模型）以及上下文，所以它也是一个显示边界。
限界上下文中的术语一定准确反映通用语言限界上下文可以是我们的一个系统。比如最初，我们要给一个图书馆客户做一个系统，包含了图书馆的书籍管理，入库、借出。然后图书馆又提出，比如某些书籍是专门卖的，然后某些书籍是专门买进来奖励一些会员的奖品。然后我们需要确定，“书”这个概念，是不是已经引起了歧义。当我们的开发人员说出书这个词的时候，可能有的人理解是需要借的书，有的人理解是回馈客户的奖品。这个时候就出现了对于“书”的理解不一致，也就违反了领域模型的通用性。我们的系统边界，应该是完整的表达一个领域模型，或者说是通用语言。这就像音乐家创作的交响乐谱一样，多一个音符不多，少一个音符不少，刚刚好好，完整而优美得可以演奏出来一篇华丽的作品。所以系统设计也是一样，我们所说的领域专家其实就是具备能细致得划分领域边界，以及从复杂的业务中抽象出来通用语言的人。所以刚才的图书馆的例子，在落地到系统中的时候，就需要考虑系统划分了。出售书的系统中的书，不会使用租书系统中的书的实体来处理自己的领域事件。
在限界上下文定义好之后，就可以划定核心域了。比如这里，图书馆的核心业务是租书来收取定期的阅读费用。那么租书上下文中的租书服务就是我们的核心域了。图书馆的场景中，还需要有一个独立的用户系统，来管理用户登录和用户基本信息。租