领域驱动设计，说起来容易做起来难

领域驱动设计（DDD）是如今的热门话题。大家已经公认，不是所有问题都可以靠程序员去解决就足够的，想要解决足够专门领域的问题，必须学习专门领域的知识， 尊重专门领域的规律， 针对专门领域进行设计。

不过在这些共识之外，怎么做DDD，共识却没有那么多，相当多的基础问题都还没有解决。

比如，很多时候专门的领域通用语言都没有建立起来，术语表都没有制定，结果业务人员和开发人员各说各话，同一个名词多种解释的情况都无法避免。

我问过不少人对这种问题的看法，答复都是“道理我们都懂，实在是没时间都做到，而且大家都叫习惯了也不好改”。这或许是实际情况，但这种情况下搞“领域驱动设计”，结果可想而知。

还有，如何划分边界？许多人都懂得“高内聚，低耦合”，但如何内聚，如何解耦合，却不是人人都说得清楚的。许多设计图看起来像模像样，设计者却搞不明白 谁和谁是一家人，谁和谁是远亲，谁和谁是近邻？

夸张点说，甚至有相当多的人不知道“异步其实是一种解耦合的方式”，也不清楚异步会引入更多的复杂度，尤其是丢失实时报错的便利，而只是简单把异步当成解决性能问题的手段，这样做出来的设计，结果也是可想而知的。

所以，尽管“领域驱动设计”很热门，但学习起来并不容易。除了公认的经典著作《领域驱动设计》，更合适的办法还是以例子来教学，经过讨论、对比、反思来理解，这样才算真正掌握了。

如果你也认同我的观点，不妨看看参考  张 逸  在 GitChat 推出的 《领域驱动设计实践·战术篇》，或许有助于加深理解领域驱动设计。

张逸曾在第一届领域驱动设计中国峰会上做过《领域驱动架构透析与架构解耦》的演讲， 在领域驱动设计领域有丰富的经验。

在探讨领域驱动战术设计的一些问题时，总会有人纠结：

• 这个领域对象应该定义成实体，还是值对象？

• 领域服务和应用服务的区别是什么？

• 聚合的边界该怎么划分？

在软件开发领域，没有什么一劳永逸的实现，也没有什么放之四海而皆准的标准，必须结合具体的业务场景做出合理的决策，无论建模和设计再怎么完美，也需要通过落地的检验才知道好还是坏。

任何脱离具体业务场景的问题分析，都是空谈； 任何不落地的完美方案，都是浮夸。 领域驱动设计没有标准，有的只是持续不断的不确定性。正所谓“以不变应万变”，我们要从实证主义的角度看待领域驱动设计，我认为，只需守住三项基本原则即可：

• 必须通过领域建模来驱动设计

• 领域专家或业务分析师必须参与到建模活动中

• 设计必须遵循面向对象分析和设计的思想与原则

只要做到这三点，领域驱动战术设计就不会做得太差，剩下的不足，就需要靠经验来填补了。

本套装的 上篇 是 《领域驱动 设计实践· 战略篇 》 课程分为五部分，共计 36 篇，已全部更新完毕。

第 1-1~1-5 课：软件复杂度

第 2-1~2-5 课：领域知识

第 3-1~3-10 课：限界上下文

第 4-1~4-8 课：架构与代码模型

第 5-1~5-6 课：EAS 系统的战略设计实践

本套装的 下篇 《领域驱动 设计实践 · 战术篇 》 正是要解决前面所提及的战术层面的设计问题。 若要做到优良的领域驱动设计，建模和设计的经验必不可少，这需要多年的项目实战打磨。但如果在开始之初，能有一些更为具体的方法作为指引，或许可以让掌握技能的周期大幅度缩短。

对于开发团队来说，决定是否采用领域驱动设计，在于业务的复杂度。我在本课程中，一方面分享了我的 设计体验和方法， 以帮助团队成员的成长，另一方面也给出了一个 操作性强的设计过程 ， 可以让基础相对薄弱的开发人员能够依样画葫芦，做出还算不错的设计与实现。

《领域驱动 设计实践 · 战术篇 》 的课程思路就是：以能学习和模仿的战术设计方法来弥补经验之不足，以设计思想和设计原则作为指导来解决争议之问题，以能够落地的解决方案来体现领域驱动设计之价值。

本课程分为六部分，共 64 篇。

第 1-1 ~ 1-15 课：软件系统中的模型

第 2-1 ~ 2-7 课：领域分析模型

第 3-1 ~ 3-17 课：领域设计模型

第 4-1 ~ 4-6 课：领域实现模型

第 5-1 ~ 5-9 课：融合：战略设计和战术设计

第 6-1 ~ 6-8 课：EAS 系统的战术设计实践

以上的两个课程还配套建立了读者交流群，同时邀请了十几位领域驱动设计方面的专家加入，共同探讨和交流领域驱动设计的相关知识。

还没订阅过《领域驱动设计实践》的新同学们，点击 阅读原文 直接订阅合集 更优惠 哦！