DDD（领域驱动开发）是前几年在国内非常火的软件开发概念，我也跟风参与其中，按照DDD的模式进行了一些项目，结果并没有预想中的成功。系统是成功上线了，但并未达到设想中提高开发效率和代码质量的效果。
DDD不是号称“软件核心复杂性应对之道” 吗？为什么会这样？是我对它的理解不好，还是团队的代码质量太差？之后我对自己之前的项目经历进行了多次反思，也学习了网上各种经验分享，并重新学习了那两本最知名的DDD著作，总结出一些粗浅的结论。
坑一：DDD 不只与技术部门相关
DDD不只是一个软件开发模型或架构设计模型，它是一整套包含软件开发整个周期的解决方案。因此，如果决定了要使用DDD，只有技术团队实施是不够的。需要整个业务链条上每一环节的人都认可并了解DDD。
DDD要求团队人员抽象出一套内部的“统一语言”，并使用这套语言进行交流。但现实是，如果只有技术部门提出这个想法，业务部门会搭理吗。一套操作下来并没有什么业务上的“收益产出”，反而平添了他们的学习成本。
因此，如果没有更高一层的leader来强势推动统一语言的建立，DDD的实践就是空中楼阁。
或者团队本身“项目组”式的组织架构。大家平时虽然也分别属于“技术部”“运营部”“客户部”，但此时此刻都是这一个项目组的成员，都对这个项目负责。比如一些游戏公司的工作室制度。这时推动的阻力就小得多。
坑二：你真的知道完整的领域是什么样子吗？
DDD 要求我们建立一个领域层，用这个领域层来描述整个领域的“知识”。但很难。
有人会说，书里讲了，要靠“领域专家”。但是对于技术系统来说，最好的领域专家就是一个完整见识过并深度参与过其它公司相同系统的资深工程师或产品经理，如果没有，其他人都很难在这种场景下被称为“领域专家”。不同的岗位看业务的角度不同，即使是公司里经常在行业沙龙里做分享的业务大佬，对行业的认知很深刻，但他对一个行业的“技术系统”的认知可能也仅限于知道它是用来做什么的，起到的作用比较有限。
有人又说了，可以通过内部的头脑风暴整理出领域知识来。这多少有点理想主义了。多数业务团队是没有耐心做这些事情的。他们想要的是把需求列出来，甚至需求都列不清楚，只是“我想要一个能xxx和yyy的系统”，剩下的技术和产品全搞定。即使整理出来
另外，多数互联网公司的系统都是在高速迭代中的，做第一个版本时谁都不知道后面会有什么需求。如果按最初设想中的系统的样子建立了领域层，在经过几个大版本的迭代后，它还能表达这个系统真实的样子吗？
我认为，在这种无法清晰建立领域知识的情况下，如果真的在这种还要上DDD，一个比较现实的想法是从一开始就放弃建立一个一步到位的领域层，并且从一开始就对自己的领域层的“不完善性”做好充分的预留，比如预留接口、预留适配层等。转而追求MVP+快速迭代；在不断迭代中打磨自己的领域层。当然这样也不是好的解决方法，因为你预留的预案可能也无法完全适应将来的变化，可能反而带来多余的冗余。
坑三：你的团队成员能理解这套架构吗
别笑！这条是认真的！如果你从毕业就一路在各种大厂、名企，可能会很难理解这件事。但是，很多团队的配置是难以想像的低。一个普通的DDD实现里，从下到上一般会有"数据层-领域层-服务层-接口层" 这四层。这四层之间的调用关系是怎么样的？哪部分代码写到领域层，哪部分写到服务层？能理解这些的已经算是熟手了。
尤其是一些想搞IT化又不想花费太多预算在这上面的传统公司，对IT的理解基本就是ERP+CRM+官网，技术团队的配置往往是一个资深带一两个老手+一群新手，很容易出现团队成员理解不了太复杂的架构的问题。这时的技术架构也需要考虑到人员的理解能力。
坑四：限界上下文的边界不好确定
确定限界上下文的边界一直是一大难题。有一种说法是需要从三个方面统筹考虑：业务逻辑、团队合作、技术实现；另一种更抽象的说法是需要按“变化”进行拆分，使拆分后的限界上下文的变化对外界的影响尽可能小。还有如四色建模法等更各种说法不一而同。 (四色建模法还是很有用的，但也只是一个辅助工具)
但有一点是确定的：无论基于哪套方法论，限界上下文边界的确定都非常依赖于设计者的经验。而这又回到了坑二的问题上，那就是——合格的“领域专家”去哪里找。
