随笔之'子系统设计的思考'
最近被人问，如何划分子系统？我当时描述了自己关于子系统的一些想法，但是很快就陷入了具体问题的讨论。事后我觉得汗颜，一个自认为还算有些见解的问题，为什么不能清晰地描述自己的想法呢。
基于对这个问题的反思，我写了如下的随笔：
架构设计中的重要内容--子系统划分。子系统有哪些类型--子系统的分类？如何分割子系统？依据什么评价子系统划分是否合理？
从软件系统的时间纬度--从无到有的过程来看，它经历了需求、开发、实施三个阶段；在这三个阶段，该系统的子系统表现为：业务子系统，逻辑(功能)子系统、部署子系统。客户需求驱动了业务子系统的划分；架构设计驱动了逻辑子系统的划分，并影响了部署子系统的划分；三个阶段子系统的划分的目的不同，但相互影响。
是否可以从其他维度分类呢？--小子鄙陋。
业务子系统
其划分反映了业务需求，因此其划分和评价的依据都比较单一，即符合客户需求。
逻辑子系统
其划分体现了系统设计的理念：除了实现功能需求，还需要满足性能、可靠性、易维护、可扩展等非功能性的需求。
为了满足功能需求，可以从以下几个出发点考虑子系统的划分：
异构。"天者,清清者上浮而为天；,地者,重浊者下凝而为地。"可见，异构系统会自然的分离为不同的子系统。这里所谓的异构包含：地理位置、主机、操作系统、实现语言等。异构子系统之间必须通过某种第三方作为桥梁才能完成数据交换。
资源，集中管理资源在开发阶段可以实现功能代码的重用，在系统的运维阶段带来成本的节省；需要权衡集中管理资源带来的开发和使用成本与收益。资源分为外部和内部资源，这里主要是针对内部资源。外部资源参考'异构'。
数据库作为资源的特例，因为其在系统数据的持久化的特殊作用，独立作为一个出发点。根据可以预见的数据增长或者数据隔离的需求而进行的分库设计，会影响到子系统的划分。
业务封装，根据粒度的不同，所划分的子系统粒度不同。业务可以跨子系统，但是最小粒度的业务不要分布在多个子系统间，即使部署时其在同一个应用中。
为了满足非功能性需求，对于子系统的划分更多是基于设计和技术的考虑。评价因此而产生的子系统划分，只有通过实际验证其满足目标指标的程度而定。
部署子系统
系统架构设计的最终体现，当系统实施时，其物理的分布。其划分直接受逻辑子系统的影响，同样部署的约束，也影响到子系统的具体分布。评价部署子系统的划分，通过验证其满足非功能性需求的程度而定。
