为何领域模型对于架构师如此重要？ https://blog.csdn.net/qq_40741855/article/details/84835212

为何领域模型对于架构师如此重要？ https://blog.csdn.net/qq_40741855/article/details/84835212

2018年12月05日 14:30:19 绝圣弃智-零 阅读数 966

 

 

 

在信息化时代，人们在碰到问题的时候，常常会但愿经过构建一套信息系统直接或间接的来解决问题。

好比说一家传统企业，在企业内部最多见的请假审批、费用报销审批这类的平常事务处理上，一开始碰到的问题是流程不够透明、员工不知找谁怎样处理，同时员工拿着纸质处处找各个审批人签字也费时费力。为此，企业一般会经过构建内部办公系统或报销系统，将流程固化透明，同时经过 app 等友好方式让员工和管理人员随时随地提交或审批请求，以此提升办公事务效率。接着还可能经过接口直接对接 HR 系统扣减员工年假天数，对接财务系统直接把报销款转帐到员工银行工资帐户里，以此来解决人工操做带来的人效问题，以及经过自动化减小人工失误问题。

再好比说，做为一家跨境电商企业，主要为中国消费者提供一个能够方便快速购买海外优质商品的平台。海外的很多商品，在品质、设计感、品牌内涵上，都胜于国内商品，消费升级的到来，国人已经适应并接受海外商品。而且多年来，国人已经养成购买全球母婴用品、化妆品、奢侈品、家居品等多种品类。可是在海淘过程当中，国人因语言文化差别致使的对海外商品品类、价格、质量等信息的不对称，加上漫长且不透明的跨境物流递送等问题，都亟待解决。为此，从信息化角度咱们会搭建 2C 电商平台来解决进口商品的国内销售问题，同时配套海外商家系统解决货源问题、物流相关系统解决履单物流配送问题等等。

总之，咱们作任何一个软件系统，都是有缘由的，都是要解决特定的问题的，不然就不必作这个系统。因此经过问题，咱们就知道了咱们须要一个什么样的系统，这个系统解决了什么样的问题。而问题能够理解成是现状与预期的落差，这个落差就是真正需求的来源，因而最后咱们就很天然的得出了一个目标，即知道了本身的需求是什么，经过作哪些事情来让将来达到预期。

接着咱们引入比较抽象的两个概念：“问题空间（Problem Space）”和“解决方案空间（Solution Space）”，以此为后续领域建模提供工具支撑。所谓问题空间，简单理解就是当前环境下业务所面临的一系列问题和背后的需求，好比上述两个例子里的相关问题需求，它属于产品规划阶段，一般是业务或产品领域专家主导进行问题需求收集描述和分析；而解决方案空间则是针对问题空间的解决方案，它思考的是如何设计实现软件系统以解决这些问题，它属于工程设计实施阶段，一般是技术专家主导的解决方案设计和实现。所以，本质上，软件开发过程能够看作是问题空间到解决方案空间的一个映射转化。以下图所示。

在问题空间里，主要是找出某个业务面临的挑战及其相关需求场景用例分析，而解决方案空间里，则经过具体的技术工具手段来进行设计实现。所以上图还能够进一步细分红以下图所示的互联网软件从业人员容易理解的一个映射转化过程。

简单理解领域和领域模型

领域（Domain）”和“领域模型（Domain Model）”概念定义网络上能够查到不少解释，这里就很少说了。它们能够简单的这样理解：

• “领域”相对于软件系统来讲，就是系统要解决的现实问题。所以也能够简单理解一个领域就对应一个问题空间，是一个特定范围边界内的业务需求的总和。

• “领域模型”则是针对特定领域里的关键事物及其关系的可视化表现。它属于“解决方案空间”，是为了准肯定义须要解决问题而构造的抽象模型，为软件系统的构建目标统一认知，是业务功能场景在软件系统里的映射转化。

好比上面的例子里，请假系统解决的问题是人力工时的问题，属于人力资源领域，对口的业务 Owner 是 HR 部门；费用报销系统解决的是员工和公司之间的财务问题，属于财务领域，对口的业务 Owner 是财务部门；跨境电商牵涉范围甚广，但本质上仍是属于电商领域。同时能够看出，每一个软件系统本质上都解决了特定的问题，都属于某一个特定领域，都实现了一样的核心业务功能来解决该领域里最核心的业务需求。好比电商平台、普通电商系统，这些都属于电商领域，只要是这个领域的系统，都会有商品浏览、购物车、下单、减库存、支付等核心环节。因此，同一个领域的系统都具备相同的核心业务，由于他们要解决的问题的本质是相似的。而之因此每一个电商平台之间又有不一样，那是因为客户群体、经营策略、商品种类、订价策略等不一样而形成的差别。因此才有这样的说法：领域来自于需求，但它却高于需求，相对于善变的需求而言，领域知识和领域模型自己是“静止”的，是“不变”的。

领域建模分为“战略建模”和“战术建模”两个层面，建模方法论也有多种，这里就再也不累述。要对领域进行建模获得优秀的领域模型，必须先要对行业领域的业务有比较深刻的理解，才能从复杂环境中找出领域核心问题，而后对它展开梳理。一般来讲，一个领域有且只有一个核心问题，咱们一般称之为该领域的“核心子域”。领域的战略建模一般就是从找出核心子域开始的。其次，在核心子域及通用子域和支撑子域梳理的同时，会定义出子域中的 Bounded Context（限界上下文）及其关系，用它来阐述子域之间的关系。最后，就是找出每一个子域中的关键领域实体进行抽象提炼，并根据业务本质找出它们之间的联系关系。

为何要建模？由于建模是帮咱们提炼出事物的本质，以便能更好的指导应用系统规划建设。看一个简单例子。企业信息化规划建设常常谈到“人、财、物”的总体管控，对于“人”这部分，从大部分行业业务角度建模，能够概括成经典的“三户模型”，即客户、用户、帐户三户模型。

其中，客户是指现实中的一个天然人或法人机构；用户则是客户在使用信息系统时对应的实体，咱们常称之为系统账号；帐户是客户存放我的资产资金的实体，相较于线下银行金融机构里的实际帐户，线上交易支付相关应用里的又称为虚拟帐户，存放虚拟货币、积分、甚至是实际货币。三户的关系在百度百科里说的比较好，它是这么说的：这三者之间的关系应该是一个相互关联但又是独立的三个实体，这种关联只是一个归属和映射的关系，而三个实体自己是相互独立的，分别是体现彻底不一样的几个域的信息，客户是体现了社会域的信息，用户体现了业务域的信息，帐户体现的是资金域的信息。三户模型最先是在电信运营领域里提出的，后来在银行、金融、第三方支付、电商等各领域获得了普遍应用。

案例：酒店管理系统 PMS

一家酒店在平常管理中的方方面面，包括客房管理、预订处理、客人入住和退房办理、在住客人的服务等，在行业里一般是由 PMS 系统来一手包办。固然大型酒店集团，还会针对每一个环节有更深刻的应用，好比中央预订系统来处理各类渠道的预订订单、CRM 处理酒店会员关系管理、房价体系系统实现动态订价、房控系统实现客房资源利用最大化等等。但回归到核心，全部酒店都共有的核心，能够概括为下面的核心业务流程：

核心业务流程具体描述以下：

1. 客户选择预订渠道下订单：客户能够选择预订渠道预订酒店连锁集团下的任一酒店，包括从官网、 app、中介 OTA（如携程网等）、呼叫中心进行预订，也能够直接步入酒店在酒店前台当场进行预订。PMS 根据客户在某时间段里须要入住的酒店和房型，结合其可用房数量和当时的房间房价进行下预订单操做。预订单一旦生成，房态会发生变化，可用房数量也发生变化，最终结帐的房价为当时下预订单时的房价。

2. 住客入住接待：住客根据预订的时间来到预订的酒店办理入住。前台根据住客提供的身份证等信息办理入住，PMS 根据入住信息生成接待单，并将房卡制好发给住客。住客根据制好的房卡入住指定的房间。

3. 住客服务接待：住客在入住期间，能够享受酒店提供的一系列礼宾服务和餐娱乐服务，好比叫醒服务、早餐服务等。每次服务接待都应在接待单里产生相应的接待服务信息；若是接待服务为收费项目时，好比餐饮服务，则须要同时进行帐务处理，加入帐单流水帐中。

4. 夜审：夜审主要是作入帐对帐及其核查。每次夜审都应该将住客房费和餐娱乐等费用进行核查，最终算入当日营业日业绩。只有夜审完成后，系统才能进行下一营业日的酒店营业操做。

5. 住客退房：住客退房时，系统须要对住客在入住期间的全部服务及其费用进行核查结算，在知足退房条件的状况下，回收房卡，并更改房间房态。

6. 客历归档：住客从入住到退房整个过程，默认将收集到的住客在期间的喜爱和反馈存入住客档案中，供后续进行客户分析和客户个性化服务使用。

酒店的核心业务是稳定可扩展的，不随市场活动等外部平常运营业务而不断变化。所以 PMS 中，平常运营业务的变化，如市场活动对房价形成的影响，或餐娱乐服务对住客帐单的影响等，都是与核心业务剥离弱化关联的，以此保证核心业务稳定沉淀的同时，系统仍然能够多变适应平常运营业务灵活多变的须要。

在理解酒店核心业务后，瓜熟蒂落能够获得酒店管理领域的核心子域——客房管理子域。这是由于酒店的全部核心业务都围绕着客房管理进行的。好比，预订房间时，最重要的是了解这家酒店的可用房信息及其相关房价、客人入住时须要关联房间并变动房态、酒店服务的收银帐务是按房间来进行挂帐买单的等等。以此为核心，经过 Bounded Context 关联各个相关子域。以下图所示：

领域中的界限上下文能够简单理解成一个子系统或组件模块，它放在哪一个子域里最为合理是受到场景制约的。有时候，一样一个业务甚至同一个实体，会出如今不一样的子域里，结合该子域的上下文来进行不一样的描述。领域和界限上下文的划分并无标准，它是依据每一个人对特定业务不一样程度的理解和抽象程度而不一样的。评判一个领域模型是否合理，只能放到特定的业务背景和场景下才会相对客观。

最后根据上述战略建模的结果，进行领域模型上的战术建模。根据核心子域里的界限上下文及核心场景，抽象出领域实体及其关系，并用概念类图的方式呈现出来。这张领域模型图也有不少的画法，但最重要的是要让业务和技术等各方干系人都能理解这张图表达的涵义，以此造成统一的共识。领域模型图怎么画并非关键，最关键的是明白领域模型要解决什么问题， 而后才能把这个问题毫无歧义的表述成一张图来凝结各方共识。战术建模获得的领域模型图，其关键就是识别出各种关键实体，以及它们之间的关系；而最终领域模型的验证反过来也是经过战略模型和核心业务场景流程来验证的。下图是酒店管理领域模型图示例。

思考总结

领域建模不是面向技术的一种纯软件设计方法，它是一种思惟方式，咱们采用它来搭建领域模型，以此弥补业务和代码之间的 Gap，促进团队合理的分工协做，同时也时刻真实的反映着咱们所要解决的问题的变化，让咱们构建的系统富有价值和生命力。

因此，领域模型的价值不在于它的设计优美﹐而在于它体现了系统的核心价值。那么什么是系统的核心价值？一个企业内部经常使用的费用报销系统和一个互联网的大型支付系统，它们本质的区别不是用了什么编程语言，也不是用了什么数据库，而是其提供的服务及其服务质量，也就是咱们最开始所说的，它能解决的问题及解决的程度。