全无设计的代码会将数据一股脑的扔到一个结构或类中，最终导致上帝类，超长的函数和超长的文件的出现。这样的实现是难以扩展，难以应对变化的。如果你的系统并不需要扩展，那怎么写都行。同时不需要扩展的系统一般意味着它基本没有价值。

分工带来能力提升

    分解系统，使之有明确的分工和结构，看起来使系统变得复杂，但这种复杂性是系统功能增强的必要的代价。人类社会和软件架构一样，复杂的社会结构(政治经济法律)和愈加细化分工带来生产力的大发展；拆分明晰/组合灵活/层次清楚的软件结构也能带来软件能力的大幅提升，这种能力就是软件更容易响应变化(或者说降低变动成本)。

    另一个角度看，如果一个系统完成的功能足够复杂，那它的本质复杂度就很高。这种本质复杂度要通过某种明确的结构展现出来，才有可能被有效管理。就好像人群，了解每个人的能力特长性格爱好等等信息，给每个人建档才能做到精细的组织管理。当然，你如果只是要这群人去挖白波运河(好比斯大林同志当年干的)，那给每个人一个编号就够了。

拆分的依据

    系统拆分的拆分，首先应该选择一个明确的，预先定义的骨架结构。预先定义是指骨架设计的原则应该是讨论明确成文的，且骨架结构不同维度上元素列表应该在架构层面被定义出来。基于这个结构，我们才能对系统中的数据和行为做一致性的拆分。一致性指 data/behavior之间的一致性，以及开发者之间理解的一致性。

    假设已经设定系统有 <module>和<feature>两个维度作为骨架结构，并且已经给出了<M>和<M>的list，那么data拆分的最大粒度就应该是一个<m，f>的交点。

结构

WHY FEATURE

    Feature是一个用户视角的概念，用户可以单独使用或者购买某个feature。系统开发早期，我们往往希望按feature来拆分module，但最终一定会出现某些或者很多feature会波及多个module。Feature之间冲突了。一个现实是，系统经常被使用的feature可能只占整个feature集合的一小部分，二八原则在这里仍然成立。想想你怎么用微信或者vscode？feature集合一天天长大，带来的问题很多，缺乏设计的代码中，出现了大量重复和复杂的判断条件，内存开销急剧增加，系统性能逐渐恶化。性能恶化对于pc和手机app可能还不是个致命问题，你不太关心今天的游戏和软件能不能跑在五年前的机器上，但有些场景可能会是致命的问题，比如电信设备，比如机载车载系统。这些硬件的生命周期可能会在10年以上。

数据和基础行为的一致性

    feature可以被关掉，意味着它对应的数据和行为都可以被有条件的忽略。忽略的前提是，需要将它们拆分出来，并提供合适的访问形式。接口访问是基础，不要暴露实现。更好的是封装行为，数据通过行为展示其功用。 

    拆分后的data应该只为一个<m，f>点服务，这是data使用的条件，feature关闭的时候依赖它的data就不应该被访问。Module存在公用数据，也存在大量有条件的数据。一个基础行为(bbhv)访问若干data，这个bbhv可用的条件就是它涉及的所有data使用条件的并集。好的bbhv的拆分，它的使用条件应该足够简单，也尽量只为一个<m，f>点服务。一个bhv在不同feature中有不同的实现，这时就需要借助abstract behavior机制了。

总结

    总结一下，要管理复杂度提升扩展性就应该对系统进行拆分，拆分之前要先给出骨架结构。<M,F>是一种可行的结构(完整的结构模型另文描述)。依据此结构拆分的data和behavior使用条件应满足一致性。