DDD如何讲清楚，做出来？

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

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

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

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

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

任何脱离具体业务场景的问题分析，都是空谈；任何不落地的完美方案，都是浮夸。

领域驱动设计没有标准，有的只是持续不断的不确定性。正所谓“以不变应万变”，我们要从实证主义的角度看待领域驱动设计，我认为，只需守住三项基本原则即可：

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

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

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

这里，我特别提一句，有人抬杠，我们项目就没有领域专家如何如何，就我的所见所闻而言，业务运营者、需求分析师、架构师包括主力开发在业务问题域共识过程中，谁理解到位，谁就是“领域专家”，可以把它看成一个角色，而不是岗位设定。

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

要掌握领域驱动设计，就不要被它给出的概念所迷惑，而要去思索这些概念背后蕴含的原理，多问一些为什么。同时，要学会运用设计原则去解决问题，而非所谓的“设计规范”。

笔者的朋友，张逸老师是DDD方面经验丰富的大牛。张逸老师强烈建议大家要学会对设计的本质思考，不要只限于对设计概念的掌握，而要追求对设计原则与方法的融汇贯通。只有如此，才能针对不同的业务场景灵活地运用领域驱动设计，而非像一个牵线木偶般遵照着僵硬的过程进行死板地设计。

去年，张逸老师的《领域驱动设计实践》系列课程在 GitChat 上发布了上篇《领域驱动设计实践·战略篇》。如今，读者们千呼万唤催更而来的下篇《领域驱动设计实践·战术篇》正式上线啦，这个上下篇的套装结合了张兄十多年来的实践领域驱动设计的经验心得，而且糅合了 DDD 社区最新发展的理论知识与最佳实践，推荐给大家学习。

感兴趣的同学，扫码特价订阅套装

▼

（套装原价 168 元，两个课程的合订套装共 100 篇）

本套装的上篇是《领域驱动设计实践·战略篇》课程分为五部分，共计 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 系统的战术设计实践

扫码试读套装下篇

《领域驱动设计实践·战术篇》

更偏向于设计与编码

▼

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

还没订阅过战略篇的新同学们，点击阅读原文直接订阅上下篇的合集套装更优惠哦！