解读《领域驱动设计 软件核心复杂性应对之道》（九）

第17章 战略设计的综合运用

前面3章给出了战略层面上应用领域驱动设计的很多原则和技术。在一个大的、复杂的系统中，可能需要在一个设计中综合运用几种策略。

17.1 用更开放的眼光看待各种策略

本章的很多模式，比如BOUNDE CONTEXT、COER DOMAIN 、大型结构中的分层，都是可以互相穿插使用的。本书只是在说一些理念和思维方式，大家不要总想着谁包含谁。很多划分要具体问题具体分析。比如大型结构中的分层，每层可能属于同一个BOUNDE CONTEXT，也可能同一个BOUNDE CONTEXT被分到多个层上。COER DOMAIN 可能是BOUNDE CONTEXT的一部分，也可能多个BOUNDE CONTEXT共同构成一个COER DOMAIN。

17.2 进行战略设计前需要先评估现状

当对一个项目进行战略设计时，首先需要清晰地评估现状。

• 画出CONTEXT MAP。判断能否画出一个一致的图，有没有一些摸棱两可的情况；
• 注意项目上的语言。有没有UBIQUITOUS LANGUAGE?语言是否足够丰富？
• CORE DOMAIN 是否被识别出来？
• 项目有没有遵循领域驱动设计；
• 开发人员是否了解领域知识？他们对领域是否感兴趣。

通过梳理现状，弄清楚最迫切需要解决的问题是什么，对症下药。

17.3 由谁制定战略设计决策

一般是由架构师进行设计。但是架构师一定要注意适当参与日常的开发工作，以免漏掉一些设计细节或设计的架构不被认可。

一个非常善于沟通、懂得自律的团队在没有核心领导的情况下，照样能很好的工作。他们能够遵循EVOLVING ORDER来达成一组共同遵守的原则。这种情况下不需要架构师的角色，也是可以的。这种一般适用于团队数量和规模比较少，相互沟通协调顺畅、且团队直接技术水平差不多的情况。

17.4 战略设计的要点

• 战略必须传达到团队每一个成员；
• 战略设计要广泛听取团队成员的意见和建议；
• 战略设计遵循“简约、小步演进”原则，这样万一决策失误，影响范围可控；
• 设计不是一成不变的，需要不断演进；
• 战略设计的架构团队要有既懂领域、又懂技术的人才。

对《领域驱动设计 软件核心复杂性应对之道》这本书的解读终于结束了。作者在最后的附录和结束语中强调：要想领域驱动设计长期发挥价值，要重视建立领域驱动设计的开发文化。同时，重视总结特定领域的固化模式，用已成型的模式指导后续的项目沟通和模块搭建。