设计原则:如何应对模型的复杂性 之 更细粒度的组织命名空间
系统分析和设计的目的是找到一个合适的模型,以及如何应对模型的复杂性(大的关系网),好的模型更多的依赖:对问题的理解、看问题的角度、经验和模式等等,而如何应对复杂性呢?这更多的是技术性的问题,本文简单的聊聊,
如何应对复杂性?我们做的只能是分解,如:
- 架构层面
- 横向分解(业务)
- 子模块
- 子模块
- 聚合
- 子模块
- 子模块
- 纵向分解(技术)
- 横向分解(业务)
- 流程层面
- 迭代
- 工作层面
- 分工
今天我想稍微重点说一下的是:更细粒度的组织命名空间。
更细粒度的组织命名空间
我们在大的层面一般都做了很好的分解(领导或架构师比较在意),而在实现层面,由于进度、历史等原因,我们的某些命名空间下有超过 50 个文件,我自己也造成过这样的结构,也深受其苦,这里不谈如何更细粒度的组织命名空间了,只给出一个我以后会遵从的原则:
备注一个业务命名空间下的文件数保持在 10 个左右。
separation of concerns.