从零开始的领域驱动设计

背景：工作驱动，公司做新系统，同事采用DDD架构模式设计，因为除了参与功能设计外，归根还是要参与业务设计，就此学习下领域驱动，网上发现了ali中间件工程师文章，描述很接地气，传送link https://blog.csdn.net/u013815546/article/details/76223449之余也记录下自己的理解几个点;

结合领域驱动设计，更加让我确定，技术方案始终有代替方案，决定微服务的不是框架的选择，不仅仅是restful或者rpc的接口设计风格的抉择，而更应该关注拆解，领域，限界上下文，聚合根等等一系列事物

---

1：模式： Entity与Value Object

以前总把把value object和常用于前台展示的view object，vo混为一谈，entity当做业务参数中专类，后面发现完全不是一回事，

2：模式 包结构: 包结构应当具有高内聚性

（业务分层包含mvc）的包结构，才是一种高内聚的包结构。第一种分层会让人有一种将各个业务模块（如mail和sms）的service和controller隔离开了的感觉，当模块更多，每个模块的内容更多，这个“隔得很远”的不适感会逐渐侵蚀你的开发速度。一种更加低内聚的反例是不用包分层，仅仅依赖前缀区分

---

前言
领域驱动的火爆程度不用我赘述，但是即便其如此得耳熟能详，但大多数人对其的认识，还只是停留在知道它的缩写是DDD，知道它是一种软件思想，或者知道它和微服务有千丝万缕的关系。Eric Evans对DDD的诠释是那么地惜字如金，而我所认识的领域驱动设计的专家又都是行业中的资深前辈，他们擅长于对软件设计进行高屋建瓴的论述，如果没有丰富的互联网从业经验，是不能从他们的分享中获取太多的营养的，可以用曲高和寡来形容。1000个互联网从业者，100个懂微服务，10个人懂领域驱动设计。

可能有很多和我一样的读者，在得知DDD如此火爆之后，尝试去读了开山之作《领域驱动设计——软件核心复杂性应对之道》，翻看了几张之后，晦涩的语句，不明所以的专业术语，加上翻译导致的语句流畅性，可以说观看体验并不是很好，特别是对于开发经验不是很多的读者。我总结了一下，为何这本书难以理解：
1. 没有阅读软件设计丛书的习惯，更多人偏向于阅读偏应用层面的书籍，“talk is cheap，show me the code”往往更符合大多数人的习惯。
2.没有太多的开发经验支撑。没有踩过坑，就不会意识到设计的重要性，无法产生共情。
3.年代有些久远，这本书写于2004年，书中很多软件设计的反例，在当时是非常流行的，但是在现在已经基本绝迹了。大师之所以为大师，是因为其能跨越时代的限制，预见未来的问题，这也是为什么DDD在十几年前就被提出，却在微服务逐渐流行的现阶段才被大家重视。

诚然如标题所示，本文是领域驱动设计的一个入门文章，或者更多的是一个个人理解的笔记，笔者也正在学习DDD的路上，可能会有很多的疏漏。如有理解有偏颇的地方，还望各位指摘。

认识领域驱动设计的意义
领域驱动设计并不会绝对地提高项目的开发效率。

                                                图1：复杂性与开发周期关系

遵循领域驱动设计的规范使得项目初期的开发甚至不如不使用它来的快，原因有很多，程序员的素质，代码的规范，限界上下文的划分…甚至需求修改后导致需要重新建模。但是遵循领域驱动设计的规范，在项目越来越复杂之后，可以不至于让项目僵死。这也是为什么很多系统不断迭代着，最终就黄了。书名的副标题“软件核心复杂性应对之道”正是阐释了这一点
模式： smart ui是个反模式
可能很多读者还不知道smart ui是什么，但是在这本书写作期间，这种设计风格是非常流行的。在与一位领域驱动设计方面的资深专家的交谈中，他如下感慨到软件发展的历史：

2003年时，正是delphi，vb一类的smart ui程序大行其道，java在那个年代，还在使用jsp来完成大量的业务逻辑操作，4000行的jsp是常见的事；2005年spring hibernate替换了EJB，社区一片欢呼，所有人开始拥护action，service，dao这样的贫血模型（充血模型，贫血模型会在下文论述）；2007年，Rails兴起，有人发现了Rails的activeRecord是涨血模型，引起了一片混战；直到现在的2017年，微服务成为主流系统架构。

在现在这个年代，不懂个MVC分层，都不好意思说自己是搞java的，也不会有人在jsp里面写业务代码了（可以说模板技术freemarker,thymeleaf已经取代jsp了），但是在那个年代，还没有现在这么普遍地强调分层架构的重要性。

这个章节其实并不重要，因为mvc一类的分层架构已经是大多数java初学者的“起点”了，大多数DDD的文章都不会赘述这一点，我这里列出来是为了让大家知晓这篇文章的时代局限性，在后续章节的理解中，也需要抱有这样的逻辑：这本书写于2004年。

模式： Entity与Value Object

我在不了解DDD时，就对这两个术语早有耳闻。entity又被称为reference object，我们通常所说的java bean在领域中通常可以分为这两类，（可别把value object和常用于前台展示的view object，vo混为一谈）
entity的要义在于生命周期和标识，value object的要义在于无标识，通常情况下，entity在通俗意义上可以理解为数据库的实体，（不过不严谨），value object则一般作为一个单独的类，构成entity的一个属性。

举两个例子来加深对entity和value object的理解。

例1：以电商微服务系统中的商品模块，订单模块为例。将整个电商系统划分出商品和订单两个限界上下文（Bound Context）应该是没有争议的。如果是传统的单体应用，我们可以如何设计这两个模块的实体类呢？
会不会是这样？
————————————————

https://www.cnkirito.moe/DDD-practice/