最近发现文章老是被窃取，有些平台举报了还没有用。请识别我的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多年的人，换了一个公司，换了一个团队，把他原有的那套带过去，推行下去，一般都不适用。