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

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

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

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