设计原则：如何应对模型的复杂性 之 更细粒度的组织命名空间

背景

系统分析和设计的目的是找到一个合适的模型，以及如何应对模型的复杂性（大的关系网），好的模型更多的依赖：对问题的理解、看问题的角度、经验和模式等等，而如何应对复杂性呢？这更多的是技术性的问题，本文简单的聊聊，

如何应对复杂性？

我们做的只能是分解，如：

• 架构层面
  • 横向分解（业务）
    • 子模块
      • 子模块
        • 聚合
  • 纵向分解（技术）
• 流程层面
  • 迭代
• 工作层面
  • 分工

今天我想稍微重点说一下的是：更细粒度的组织命名空间。

更细粒度的组织命名空间

我们在大的层面一般都做了很好的分解（领导或架构师比较在意），而在实现层面，由于进度、历史等原因，我们的某些命名空间下有超过 50 个文件，我自己也造成过这样的结构，也深受其苦，这里不谈如何更细粒度的组织命名空间了，只给出一个我以后会遵从的原则：

一个业务命名空间下的文件数保持在 10 个左右。

备注

 separation of concerns.