软件开发项目中的关键决策:基于上下文图的策略性领域驱动开发(4)

　　图14. 上下文图的最新版本。不要指望它是“最终”的，我们总是会学到一些新的东西。

　　涉及到的上下文还可能更多，比如“交易”模块可能需要链接到一些在线股票价格服务，但这是交易模块的事!这个上下文图是关于我们(团队A)的，我们的工作内容是“银行”和“开销跟踪”模块：我们只对直接关联的、会影响到自身软件的那些上下文感兴趣。

　　一旦我们收集到更多的信息，上下文图就会变得更加清晰。正如前面提到的，只要认识到应用程序中存在着各种不同的模型，而且这些模型的完整性可以在一个良好定义的有界上下文中得以保存，这会为我们的领域建模的视角提供诸多益处。很多模型都在成长的过程中逐渐失去完整性，上下文图会在这个方面给予我们很多帮助。

　　谈谈策略性DDD模式

　　此处我们使用模式的方式略有不同：尽管定义是一样的——为一类反复出现的问题提供解决方案——但这些模式很少能展现出可供我们选择的解决方案。更可能的场景是，组织架构会决定模式，我们惟一的希望就是在事态走到死胡同以前识别出它们。有些时候我们有机会选择最好的选项，或者改变现有的状况，但是我们必须清楚的是，在组织级别的改变所需的时间可能已经远远超过了项目持续的时间，或者这个改变根本就是不可能的。

　　如果你还在犹豫应该从那里开始，那么就从开发团队开始吧。对于有效地共享模型信息来说，一个团队应该是最大的组织单元。当识别出多个上下文后，可以由一个团队管理它们，这样很大程度上将问题归结为架构的抉择。

　　每一种模式都有不同的开销：即使它们解决的是类似的问题(相近的上下文)，也不能简单地交换。比如，反腐化层会在代码层面(一个额外层)上留下痕迹，并在组织里留下很小的痕迹。尽管Partnership或者“客户-供应者”模式可能需要更少的代码和一个单独的代码库，但是如果没有有效的沟通渠道和良好的过程的话，也很难应用起来。企图在没有合作的环境下安排执行Partnership模式，无异于自寻死路。

　　结论

　　让我们在回到“上下文”最初的定义上来——“一个单词或一个句子所出现的环境，这个环境会反过来影响它们的含义”——它非常准确，而且可以应用在设计层面、架构层面乃至组织层面上，却没有损失其准确性和有效性。尽管有些“对统一性的期望”是合情合理的，但是模型不能被无限地扩张。界限上下文提供了一种非常安全的机制，它允许模型在其内部不断变得复杂，同时又不牺牲概念的完整性。

　　当把上下文图应用到大型的项目上后，它还可以显示出当前组织内的隐式边界，并提供一个来自第一手的、没有PS过的项目境况的快照。一个好的上下文图能让你看到所面对的不利条件的大致状况。可能你已经知道——但通常都是不知道——组织是否在扮演项目成功的绊脚石，即使项目还没有开始。

　　作为一名顾问，我发现上下文图能够奇迹般地让我快速获取客户项目的细节。上下文图还充当了策略决策的支持工具(毕竟，这是“图”的本意)。上下文图提供了系统的全局视图，帮助我们关注在选择那些能在你的环境中真正可行的方案，而不是把钱浪费在对系统不切实际的构想中，这是UML或者架构图所做不到的。

　　关于作者

　　Alberto是来自Avanscoperta的一名咨询顾问和培训师。他致力于帮助客户管理软件开发的复杂度。他坚信只有那种全盘考虑的软件开发方法才能开发出有用的软件。

原文转自：http://www.ltesting.net