组织结构的领域建模 (0): 写在前面
对于软件开发来说，领域建模是最重要的活动，领域模型是最重要的产物。领域模型反映了软件所要服务的现实业务领域的本质，体现了我们对业务领域的认识、理解和洞见。
领域模型应该是一切领域开发活动的出发点和依归。
本系列文章以组织结构的领域建模为例，演示领域建模的方法和技巧。
领域模型的重要性
领域模型的重要性体现在：
领域模型的正确性决定了软件在业务上的正确性。
领域模型代表我们对问题域——即软件所要服务的现实业务领域——的组成、结构、行为、机制和规则的认识和理解。模型错误就是对问题域的认识错误，根据错误的模型开发出来的软件（解决方案）必然错漏百出，不符合业务需要。正如同解数学题，如果我们对试题的理解是错误的，我们给出的答案必然是错的。正如同赛跑，如果方向错误了，跑得快是没有什么用的。高超的设计思想和编码技巧都无法弥补领域模型的缺陷。
领域模型的抽象性决定了软件在未来业务上的扩展性。
我们知道在问题域中，既存在共性，也存在个性。好的领域模型通过抽象和分解等等方式，既实现了共性，也使个性化成为可能。不好的领域模型，或者无法进行个性化扩展，或者扩展的成本很高，需要对系统进行伤筋动骨的改动。
好的领域模型既满足当前客户的需要，也支持相同领域其他客户的需要；既符合当前业务需要，也支持未来业务扩展的需要。无论是在空间还是时间上的扩展，都可以低成本实现，与此同时，系统现有部分的正确性和可靠性丝毫不受影响。
领域模型超然于具体的软件实现技术，在软件技术不断更新换代的同时发挥恒久的价值。
软件实现技术是日新月异的，语言、类库、框架会不断升级和更换，但只要业务领域没有变化，我们就不需要更换领域模型。我们需要做的，只不过是以不同的编程语言、不同的类库框架、不同的架构思想，去实现相同的领域模型。“天不变，道亦不变。”问题域是“天”，领域模型就是这个“道”，只要问题域这个“天”不变，领域模型这个“道”也不需要变，只有软件技术这样的“术”才需要频繁变更。
本系列博文以组织结构这个问题域为例，体现领域模型的进化过程。我们先从一个简单的模型开始，通过对问题域的深入分析，逐步洞悉业务领域的本质，推动领域模型的进化，最终达成一个简单的、通用的模型，既体现了组织结构领域的共性，又允许进行个性化的扩展，同时扩展的成本非常低。
本文从Martin Fowler的《分析模式》一书中得益甚多。Party和Accountability等概念直接来自《分析模式》一书。但我的抽象过程和最终抽象与该书还是有所不同，请读者自行鉴别。
组织结构问题域说明
每个组织——党政机关、企业、事业单位等等——内部都存在组织结构。对于党政机关，有国家、省、市、县、镇、乡、村、部、厅、局、处、科、股；对于公司，有总公司、分公司、子公司、事业部、部门、科室；对于高校，有大学、学院、系、专业，等等等等。机构之间形成树形的层级关系，有的组织中还存在多个维度的组织层级，例如市公安局行政上级是市政府，业务上级是省公安厅。员工由某个组织雇佣，在某个机构担任一个职位，有的员工还会在多个机构担任不同的职位。除了上述各种实体和关系之外，还有职系、职级、职等等等各种概念……
读到这里，是不是脑子里充满了混乱和疑问？这是每个人面对新领域时候的正常反应——天才除外。下面的系列文章，将从混沌中寻找秩序，最终建构一个易于理解、易于扩展的相对完善的领域模型，各种概念各归其位，形成一个有机的整体。
关注领域建模，而不是领域模型
再次说明，下面的系列文章，不是从一开始就建构一个完美的模型，而是从简单开始建立一系列模型，不断草拟，又不断舍弃，形成新的模型，逐步趋于至善。这个就是真实世界中的真实的领域建模过程。
重要的不是领域模型这个最终产物，而是领域建模这个寻寻觅觅的过程，是“求道”过程中的思考洞察和权衡取舍。
金源诗人元好问《论诗三十首》中有这样的句子：
1 | 鸳鸯绣了从教看，莫把金针度与人。 |
绣得栩栩如生的鸳鸯织锦不重要，刺绣的针法才重要。不要黄金，要点石成金的那根手指。
所以：
1 | 别关注领域模型（Domain Model），关注领域建模（Domain Modeling）。 |
掌握了领域建模的技巧，你可以在不同的领域创建无数优秀的领域模型。领域建模的技巧，就是绣鸳鸯的针法，就是点石成金的那根手指。
领域建模的技能是一种可以习得技能，要掌握它，需要的是勇气，而不是天赋。