领域驱动设计(domain driven design)战略篇之一 战略 & Bounded Context

之前的文章主要从战术层面的角度介绍了ddd。在岛国也被称为轻量级ddd。它提供了一些概念如aggregate, entity, domain event和一些设计模式如repository, specification来帮助我们建模和设计。各种战术还有能够扩展的地方，有机会还会再写下去。不过从这篇文章开始会写一写ddd战略方面的知识。

战略 vs 战术

究竟什么是战略与战术？他们有什么区别？
目测这两个词都来源于战争（自己的理解），战术是偏微观的策略，目的是取得某场战斗或者战役的胜利。诱敌深入，敌进我退之类的可能都属于战术吧。而战略是偏宏观的策略，目的是赢得一场战争，它所关注的不限于军事方面，可能资源的调配，甚至会牵涉到外交等。
扯远了～在领域驱动设计[domain driven design]中战术与战略的概念亦是如此。战术是微观层面的。在之前的文章中的例子中，基本都是为了解决某个十分具体问题而进行的模型设计。这些设计会反应具体的细节。比如一个如何去识别一个entity,一个entity会有什么样的行为。而这些设计会直接反映到我们的代码上。

为什么需要战略

从很抽象的概念上来说，我们应该不难理解为什么我们需要战略。战略与战术他们需要解决的是不同层面的问题。当我们谈宏观问题时，自然是需要战略的。但话是这么说，什么从程序开发的角度来说，什么才是宏观问题？什么又是微观问题？这个好像很难用语言来具体地定义。
假设我们完全不考虑宏观问题。我们想象（想象…）一下只用ddd中介绍的战术知识来进行设计。如今互联网产品的行业可能比较现实的制造产品的方案会是，先做proto type，然后做mvp(minimum viable product 只包含核心功能的产品)，然后在mvp的技术上进行后续开发。

mvp

当我们在开发mvp的阶段时，产品的需求可能相对简单。我们分析需求，业务逻辑，然后设计能够描述这些业务的模型。可能10个到20个左右的aggregate就能解决问题。画个简图来表示我们定义的aggregate和其中的entity, value object。

这个时候你的application层的application service可能不需要与很多aggregate交互。

产品进化

随着产品经理对产品的认识更加深入，我们需要追加更多的开发，为了应对新的需求，我们要调整现有的模型，也需要增加新的模型来应对。某个时点，我们可以能已经到达了像图中的一个状况。我们已经无法再在一张图中精确描述aggregate中的元素。

而此时，我们的application层的中的一些application service可能已经不得不与非常多的aggregate进行交互。

当appli