可落地的DDD(1)-目标讨论

最近发现文章总是被窃取，有些平台举报了尚未用。请识别个人id方丈的寺院。

摘要

DDD领域驱动设计，起源于2004年著名建模专家Eric Evans发表的他最具影响力的著名书籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文译名：领域驱动设计,以后进行了不少迭代和演化，不过大多没有脱离这本书讨论的范围。由于Eric Evans在该书中只是提供了一套原始理论，并无提供一套方法论，更别说可落地。因此十几年，对于DDD争论不休，毁誉参半，喜欢的人以为他解决了软件设计的复杂性，不喜欢的人以为他使得代码设计更加复杂了。

关于DDD的理论讨论，案例分析的博客也浩如烟海，可是关于他应该如何被引进团队，一步步实施下去，却不多见，致使不少人想从0开始的人，不知道如何开始。因此我在写DDD系列开始前，先写一下DDD是如何在咱们团队落地，但愿可以对你有所启发。

DDD落地为何这么难

敏捷迭代，放弃建模

现代互联网产研团队的构成通常是市场/运营、产品、UI交互、前端、后端、测试。这些角色的分工是将一个产品开发上线的各个过程拆分出来，而后每一个过程专人负责，能够有效提升生产效率，这一套流程是标准的流水线做业。这样作的好处毋庸置疑，坏处也很明显，每一个人只盯着本身那一块，而忽略总体了。

再来看DDD,领域建模设计核心有两个

• 统一语言(软件的开发人员/使用人员都使用同一套语言，即对某个概念，名词的认知是统一的）
• 面向领域（以领域去思考问题，而不是模块）

为了实现这两个核心，须要一个关键的角色，领域专家。他负责问题域，和问题解决域，他应该通晓研发的这个产品须要解决哪些问题，专业术语，关联关系。这个角色通常团队是没有配备的。最接近这个角色的就是产品了，但实际上产品并非干这个活的。在咱们团队落地过程当中，有一段时间苦于没有领域专家，我想push产品成为领域专家，担当起这个角色。 最后不了了之，产品很配合，可是内驱力不强。为何内驱力不强，由于给他带来的收益不够。

前面已经提到敏捷迭代后，每一个角色都是流水线上的螺丝钉，你们都只盯着本身这一块。对本身有利的去参与，和本身无关的无论。

咱们先看统一语言与面向领域的好处

• 由于你们都使用统一的一套通用语言，因此沟通成本会大大减少，不会在讨论A的时候觉得是B。
• 对使用产品的用户有好处，他能在产品不断更新过程当中，有一套统一流畅的体验。用户不用在每次软件更新时都要抱怨为何以前的一个数据保存后没有用到了。
• 面向领域去开发产品有助于咱们深刻分析产品的内在逻辑，专一于解决当前产品的核心问题，而不是冗余的作不少功能模块，或者几个用户/运营反馈的问题就去更改产品逻辑，完了上线后用户不用，你还在那边骂用户朝秦暮楚，乱提需求。

这些好处粗看一下，其实对产品研发的各个角色都有意义。但细看一下呢，沟通成本大大减少，对于运营，产品，UI交互没啥问题。一个问题理解的不一致，组织个会议，你们好好聊聊就好了。用户体验一致对产研团队有啥好处呢，反正用户骂的不是我，是客户和运营。深刻分析产品的内在逻辑有啥用呢？一款产品的成功有不少因素，主要靠上面，我只是一个小兵，我管不了那么多。有空我多研究研究个人专业领域，多去看几篇面试文章。产品黄了，我好跳槽。

由于本人是后端研发，因此这里不对其余角色过多展开。只想对研发说，你跳槽换个公司就行了吗？仍是crud boy。仍是重复着写着不少冗余的功能，冗余的代码。需求方让你写什么，你就写什么，最后在一每天的加班中丧失了对代码的兴趣，没有了梦想。 咱们都知道改变别人很难，因此先从改变本身开始，先让本身变优秀了，才能影响他人

框架易学，思想难学

若是抛开其余角色，单从研发角度考虑DDD呢。开发进行领域建模，而后听从康威定律，将软件架构设计映射到业务模型中。（虽然这个领域，开发可能识别的不对，暂且忽略这个问题）

康威（梅尔·康威）定律 任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上 都与该组织的沟通结构保持一致。

纯研发实施DDD,为何也这么难呢？

没有标准

DDD是一套思想，一套领域建模设计，一套在特定上下文环境中使用的。因此在1千个团队中实行DDD,可能有1千套不一样的方案。一个实行DDD多年的人，换了一个公司，换了一个团队，把他原有的那套带过去，推行下去，通常都不适用。

因此DDD的学习和实践不像学习一个函数，API，框架那样有直接的反馈效果，他须要结合团队的实际状况去实行，才能达到效果。

期待DDD解决全部的问题

程序员都是很实际的，没有好处的东西是不会去作的。你必须可以有效的帮助他提高，他才会去接受。 好比当初有团队成员提出来，

咱们实行了这一套后，是否是不用加班了，或者加班时间能够减少。

有测试提出

实行这一套后，bug率能下降多少。

研发须要一个能够量化的效果，抱歉DDD作不到。没有哪一个团队实行了DDD后，解决了软件开发的全部问题。关于这一点，能够读一下驱动方法不能改变任何事情

DDD落地的目标

结合咱们团队的实际状况，通过上面一系列的讨论，咱们首先肯定了咱们期待的DDD落地的目标

• 结合DDD的理论支持，使得微服务架构可以落地，将一个单体应用很好的拆分红各个微服务，可以快速迭代，快速发布知足业务需求。
• 团队成员写出来的代码风格比较统一 每一个人知道代码往哪一个地方写，新人来了，可以很快上手。

以后咱们就围绕着这个目标，开始实行DDD，欲知后事如何，请听下回分解。

延伸阅读

可落地的DDD的(2)-为何说MVC工程架构已通过时

可落地的DDD(3)-如何利用DDD进行微服务的划分

关注【方丈的寺院】，第一时间收到文章的更新，与方丈一块儿开始技术修行之路