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