组织结构的领域建模 (0): 写在前面

自古美人都是妖i 提交于 2019-12-22 13:13:17

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

对于软件开发来说,领域建模是最重要的活动,领域模型是最重要的产物。领域模型反映了软件所要服务的现实业务领域的本质,体现了我们对业务领域的认识、理解和洞见。

领域模型应该是一切领域开发活动的出发点和依归。

本系列文章以组织结构的领域建模为例,演示领域建模的方法和技巧。

领域模型的重要性

领域模型的重要性体现在:

  1. 领域模型的正确性决定了软件在业务上的正确性。

    领域模型代表我们对问题域——即软件所要服务的现实业务领域——的组成、结构、行为、机制和规则的认识和理解。模型错误就是对问题域的认识错误,根据错误的模型开发出来的软件(解决方案)必然错漏百出,不符合业务需要。正如同解数学题,如果我们对试题的理解是错误的,我们给出的答案必然是错的。正如同赛跑,如果方向错误了,跑得快是没有什么用的。高超的设计思想和编码技巧都无法弥补领域模型的缺陷。

  2. 领域模型的抽象性决定了软件在未来业务上的扩展性。

    我们知道在问题域中,既存在共性,也存在个性。好的领域模型通过抽象和分解等等方式,既实现了共性,也使个性化成为可能。不好的领域模型,或者无法进行个性化扩展,或者扩展的成本很高,需要对系统进行伤筋动骨的改动。

    好的领域模型既满足当前客户的需要,也支持相同领域其他客户的需要;既符合当前业务需要,也支持未来业务扩展的需要。无论是在空间还是时间上的扩展,都可以低成本实现,与此同时,系统现有部分的正确性和可靠性丝毫不受影响。

  3. 领域模型超然于具体的软件实现技术,在软件技术不断更新换代的同时发挥恒久的价值。

    软件实现技术是日新月异的,语言、类库、框架会不断升级和更换,但只要业务领域没有变化,我们就不需要更换领域模型。我们需要做的,只不过是以不同的编程语言、不同的类库框架、不同的架构思想,去实现相同的领域模型。“天不变,道亦不变。”问题域是*“天”,领域模型就是这个“道”,只要问题域这个“天”不变,领域模型这个“道”也不需要变,只有软件技术这样的“术”*才需要频繁变更。

本系列博文以组织结构这个问题域为例,体现领域模型的进化过程。我们先从一个简单的模型开始,通过对问题域的深入分析,逐步洞悉业务领域的本质,推动领域模型的进化,最终达成一个简单的、通用的模型,既体现了组织结构领域的共性,又允许进行个性化的扩展,同时扩展的成本非常低。

本文从Martin Fowler的《分析模式》一书中得益甚多。Party和Accountability等概念直接来自《分析模式》一书。但我的抽象过程和最终抽象与该书还是有所不同,请读者自行鉴别。

组织结构问题域说明

每个组织——党政机关、企业、事业单位等等——内部都存在组织结构。对于党政机关,有国家、省、市、县、镇、乡、村、部、厅、局、处、科、股;对于公司,有总公司、分公司、子公司、事业部、部门、科室;对于高校,有大学、学院、系、专业,等等等等。机构之间形成树形的层级关系,有的组织中还存在多个维度的组织层级,例如市公安局行政上级是市政府,业务上级是省公安厅。员工由某个组织雇佣,在某个机构担任一个职位,有的员工还会在多个机构担任不同的职位。除了上述各种实体和关系之外,还有职系、职级、职等等等各种概念……

读到这里,是不是脑子里充满了混乱和疑问?这是每个人面对新领域时候的正常反应——天才除外。下面的系列文章,将从混沌中寻找秩序,最终建构一个易于理解、易于扩展的相对完善的领域模型,各种概念各归其位,形成一个有机的整体。

关注领域建模,而不是领域模型

再次说明,下面的系列文章,不是从一开始就建构一个完美的模型,而是从简单开始建立一系列模型,不断建立,又不断舍弃,形成新的模型,逐步趋于至善。这个就是真实世界中的真实的领域建模过程。

重要的不是领域模型这个最终产物,而是领域建模这个寻寻觅觅的过程,是*“求道”*过程中的思考洞察和权衡取舍。

金源诗人元好问《论诗三十首》中有这样的句子:

​鸳鸯绣了从教看,莫把金针度与人。

绣得栩栩如生的鸳鸯织锦不重要,刺绣的针法才重要。不要黄金,要点石成金的那根手指。

所以:

​别关注领域模型(Domain Model),关注领域建模(Domain Modeling)。

掌握了领域建模的技巧,你可以在不同的领域创建无数优秀的领域模型。领域建模的技巧,就是绣鸳鸯的针法,就是点石成金的那根手指。

领域建模的技能是一种可以习得技能,要掌握它,需要的是勇气,而不是天赋。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!