DDD在微服务中的应用

学习与应用 DDD 有一年半的时间了，今天用最简短的文字去记录一下我们在微服务中应用 DDD 的实践的经验，了解 DDD 与微服务的朋友也许听过一句话：微服务与 DDD 相结合应用相得益彰，首先在讨论微服务之前，我们先了解一下什么是 DDD,（这个系列会有三篇文章）DDD 全名叫做 domain-driven design 翻译成中文叫做领域驱动设计。

DDD 是什么？

那我们首先把这个词拆开来看：领域 驱动 设计
首先是领域 什么是领域？
领域是指某个范围，
什么是驱动？
驱动是指某物推进某事
什么是设计？
设计模式大家应该都了解过 这个设计与设计模式相类似。
连起来看就是范围推进设计或者说设计人员将领域专家的领域知识翻译成特定的设计 此处的设计人员是指计算机工程师，这是我个人见解，下面看看维基百科的定义：

领域驱动设计（英语：Domain-driven design，缩写 DDD）是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。领域驱动设计的前提是：

• 把项目的主要重点放在核心领域（core domain）和域逻辑
• 把复杂的设计放在有界域（bounded context）的模型上
• 发起一个创造性的合作之间的技术和域界专家以迭代地完善的概念模式，解决特定领域的问题

该词是由埃里克・埃文斯（Eric Evans）在其同名书中创造.

DDD 的一些概念

领域专家、通用语言、领域模型、战略建模、战术建模。

领域专家: 领域专家，有时也称为主题专家，是非常重要的资源。他们对软件应用领域的了解程度对软件的成败有直接影响。

通用语言：领域专家与软件工程师之间沟通的语言 如：用户这个名词，在电商系统时可以是买家卖家管理员这些角色在特定的上下文中用户指的概念是不同的；还有订单号有时是指自有系统的订单号，有时是指天猫的订单号，有时是指 WMS 中的订单号，虽然都是订单号但在特定上下文中指代的是不同事物概念，而这里如何区分这些订单号就需要加上上下文也就是前文中的范围；如自有系统中的订单我们称其为系统订单，天猫订单我们称其为天猫订单；而这里的范围就是领域，领域可大可小，视其耦合紧密程度而定，而正是这些领域的划分是领域驱动中最困难的事物。

领域模型：描述某一事物或范围的一种模型或结构，可以是图文也可是 UML 或代码，通常对于软件开发工程师是代码 也就是描述某一事物的一组对象或服务，所以领域驱动相对于数据库驱动设计更加面向对象，编写也更困难一些，但其带来的好处也是显而易见的后期代码越来越多某件事物的某个动作与行为不会散布在各处，他们有自己专属的领域位置，项目越大效果越佳。

战略建模：是指领域对象与服务的划分与领域之间上下文的映射，是范围之间如何联系与划分的指导。

战术建模：是将领域模型通过代码实现的的一种模式与方法，在后面的文章中会仔细讲这一块。

DDD 应用

了解与熟悉领域的边界与合理划分领域的职责，各司其职，前期领域知识的了解与领域的划分要和领域专家充分的交流沟通，技术手段通过进程或模块或类将不同的领域隔离开来。

欢迎大家评论！

参考资料

Domain-Driven Design