第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 战略设计的要点
- 战略必须传达到团队每一个成员;
- 战略设计要广泛听取团队成员的意见和建议;
- 战略设计遵循“简约、小步演进”原则,这样万一决策失误,影响范围可控;
- 设计不是一成不变的,需要不断演进;
- 战略设计的架构团队要有既懂领域、又懂技术的人才。
对《领域驱动设计 软件核心复杂性应对之道》这本书的解读终于结束了。作者在最后的附录和结束语中强调:要想领域驱动设计长期发挥价值,要重视建立领域驱动设计的开发文化。同时,重视总结特定领域的固化模式,用已成型的模式指导后续的项目沟通和模块搭建。