到目前为止，我们尽己所能找到了整合子系统的途径，使它们协同工作，并且是在建模和设计都做得很好的情况下。这需要努力和妥
协。工作于各自子系统的团队需要花费大量的时间理清子系统之间的关系，需要持续不断地融合他们的代码，执行测试以保证没有破
坏任何部分。有时，某个团队还需要花费很多时间去实现其他团队需要的一些请求。妥协也是很有必要的。一方面是你独立做开发，

自由地选择概念和联盟，另一方面要确保你的模型适合另一个系统的框架。我们也许会为了能和另一个子系统协同，而修改模型。或
者有可能需要引入特殊的层，在两个子系统之间做转换。有时我们必须这样做，但有时也可以采用其他的方法。我们需要严格地评估
整合的价值，只在做这件事确实有价值时才去做。如果我们得出的结论是整合难度很大，不值得这样去做，那么就应该考虑独立方
法。

独立方法模式适合一个企业应用可由几个较小的应用组成，而且从建模的角度来看彼此之间有很少或者没有相同之处的情况。它有一
套自己的需求，从用户角度看这是一个应用，但是从建模和设计的观点来看，它可以由有独立实现的独立模型来完成。我们应该现看
看需求，然后了解一下它们是否可以被分割成两个或者多个不太相同的部分。如果可以这样做，那么我们就创建独立的界定上下文
（Bounded Context），并独立建模。这样做的好处是有选择实现技术的自由。我们正创建的应用可能会共享一个通用的瘦GUI，作为
链接和按钮的一个门户来访问每一个程序。相对于集成后端的模型，组织应用是一个较小的集成。

在继续谈论独立方法之前，我们需要明确的是我们不会回到集成系统。独立开发的模型是很难集成的，它们的相通之处很少，不值得
这样做。