软件系统业务架构拆分问题？

Question

在实现一个软件系统的时候，如果所涉及到的概念实体、关系、过程较多，那么无论是出于控制复杂度的需要还是其他原因，往往会把这个系统分解为多个子系统，而在分解系统的时候，也就是将概念实体、关系、过程分解到不同的子系统中，在这个分解的过程中，是如何决定哪些实体、关系、过程应该放到哪个子系统中的呢？有些时候，我们在分解系统的时，往往会说xx子系统不应该理解yy这个概念，当我们这样说的时候，我们究竟想表达的是什么意思呢？为什么xx子系统不应该理解yy这个概念呢？还望哪位大神可以详细解惑一下。

Answer 1

这里的拆分的主要方法是：
（1）按照业务拆分，不同的业务独立。独立的意思是，不需要别的系统存在，它独自就能工作。
（2）按照业务是否会频繁变化拆分，将不变的作为主体，会变化的分层或者作为插件
（3）按照开发者的职责分工拆分。

会说xx子系统不应该理解yy这个概念
的意思是yy单向依赖xx，xx不依赖yy。或者说，修改yy，不需要动xx的源代码，就能实现。
比如说，你的程序单向依赖类库，你要增加功能，修改你的代码就可以了，不需要c++类库为了你的程序而发布一个新版本。对吧。
只有这样，那么类库才能通用。