Why domain model is so important for an architect? https://blog.csdn.net/qq_40741855/article/details/84835212
In the information age, when people have problems, often you will want to resolve the issue directly or indirectly, by building an information system.
For example, a traditional enterprises, within the enterprise the most common leave approval, reimbursement approval on such a routine transaction processing, the beginning of a problem encountered is lack of transparency in the process, we do not know who to turn to how to deal with employees, while employees holding paper to find that each person signing the approval is also time-consuming. For this reason, companies often by building an internal office system or the reimbursement system, the curing process transparent, while allowing employees and managers by the friendly app, etc. submit a request for approval or at any time, in order to improve the efficiency of office work. Then you may also deduct annual leave days employees directly through the interface docking HR systems, financial systems directly to the docking transfer reimbursement to employees of the bank payroll account in order to solve human problems caused by manual operation efficiency, and reduce human error through automation problems .
Suppose, for example, as a cross-border commercial enterprises, mainly Chinese consumers can quickly and easily buy a high-quality merchandise overseas platform. Many overseas merchandise, in terms of quality, design, and brand are better than domestic goods, consumption upgrade soon, people have adapted and accepted overseas goods. And over the years, people have developed a variety of categories of global purchasing baby products, cosmetics, luxury goods, household goods. But in the process of scouring the sea, people because of language and cultural differences lead to asymmetry of overseas commodity categories, prices, quality and other information, coupled with lengthy and opaque cross-border delivery logistics and other issues are to be solved. For this reason, from the point of view of information we will build 2C electronic business platform to address the problem of domestic sales of imported goods, while supporting overseas business systems to solve the supply problem, logistics related logistics and distribution system to solve problems, and so a single shoe.
In short, we do whatever a software system for a reason, is to solve a particular problem, otherwise there is no need to do this system. So by the problem, we know what we need a system that solves what kind of problems. The problem can be understood as a status quo with the expected gap, this gap is the source of real needs, so it is natural that we finally reached a goal, that is, to know what their needs are, what things to do to make through to reach the future expected.
Then we introduce two more abstract concepts: "the problem space (Problem Space)" and "solution space (Solution Space)", in order to provide support for the follow-domain modeling tools. The so-called problem space, simple to understand the needs of a range of issues behind the current environment and business are facing, such as the above two examples in issues related to demand, it belongs to the product planning stage, usually a business or product experts were dominant issue needs collection description and analysis; and the solution space is a solution for the problem space, it is to think about is how to design and implementation of software systems to solve these problems, it belongs to the engineering design implementation phase, usually a solution design and implementation of technical experts led . So, in essence, the software development process can be seen as the problem space to solve a mapping transformation program space. As shown below.
In the problem space, the main challenge is to find a business and its related demand scenario faced by use case analysis, and solution space, is designed to achieve by means of specific technical tools. Thus figure can be further subdivided into as shown in Internet software professionals readily appreciated by a mapping transformation.
Simple to understand the field and the domain model
FIELD (Domain) "and" Domain Model (Domain Model) "can be found many explanations on the definition of the concept of network, here is not to say they can simply be understood:
-
"Field" with respect to the software system, is the system to solve practical problems. And therefore can be simply understood on a field corresponding to a space problem, it is the sum of service requirements within a particular range boundaries.
-
"Domain model" is the visual representation of the key things for their specific areas of the relationship. It belongs to the "solution space" is an abstract model in order to accurately define the problem to be solved constructed, the goal is to build a unified cognitive software systems, business functions scene is mapped in the transformation of the system software.
比如上面的例子里，请假系统解决的问题是人力工时的问题，属于人力资源领域，对口的业务 Owner 是 HR 部门；费用报销系统解决的是员工和公司之间的财务问题，属于财务领域，对口的业务 Owner 是财务部门；跨境电商牵涉范围甚广，但本质上还是属于电商领域。同时可以看出，每个软件系统本质上都解决了特定的问题，都属于某一个特定领域，都实现了同样的核心业务功能来解决该领域里最核心的业务需求。比如电商平台、普通电商系统，这些都属于电商领域，只要是这个领域的系统，都会有商品浏览、购物车、下单、减库存、支付等核心环节。所以，同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。而之所以每个电商平台之间又有不同，那是由于客户群体、经营策略、商品种类、定价策略等不同而造成的差异。所以才有这样的说法：领域来自于需求，但它却高于需求，相对于善变的需求而言，领域知识和领域模型本身是“静止”的，是“不变”的。
领域建模分为“战略建模”和“战术建模”两个层面，建模方法论也有多种，这里就不再累述。要对领域进行建模得到优秀的领域模型，必须先要对行业领域的业务有比较深入的理解，才能从复杂环境中找出领域核心问题，然后对它展开梳理。通常来说，一个领域有且只有一个核心问题，我们通常称之为该领域的“核心子域”。领域的战略建模通常就是从找出核心子域开始的。其次，在核心子域及通用子域和支撑子域梳理的同时，会定义出子域中的 Bounded Context（限界上下文）及其关系，用它来阐述子域之间的关系。最后，就是找出每个子域中的关键领域实体进行抽象提炼，并根据业务本质找出它们之间的联系关系。
为什么要建模？因为建模是帮我们提炼出事物的本质，以便能更好的指导应用系统规划建设。看一个简单例子。企业信息化规划建设经常谈到“人、财、物”的整体管控，对于“人”这部分，从大部分行业业务角度建模，可以归纳成经典的“三户模型”，即客户、用户、账户三户模型。
其中，客户是指现实中的一个自然人或法人机构；用户则是客户在使用信息系统时对应的实体，我们常称之为系统帐号；账户是客户存放个人资产资金的实体，相较于线下银行金融机构里的实际账户，线上交易支付相关应用里的又称为虚拟账户，存放虚拟货币、积分、甚至是实际货币。三户的关系在百度百科里说的比较好，它是这么说的：这三者之间的关系应该是一个相互关联但又是独立的三个实体，这种关联只是一个归属和映射的关系，而三个实体本身是相互独立的，分别是体现完全不同的几个域的信息，客户是体现了社会域的信息，用户体现了业务域的信息，账户体现的是资金域的信息。三户模型最早是在电信运营领域里提出的，后来在银行、金融、第三方支付、电商等各领域得到了广泛应用。
案例：酒店管理系统 PMS
一家酒店在日常管理中的方方面面，包括客房管理、预订处理、客人入住和退房办理、在住客人的服务等，在行业里通常是由 PMS 系统来一手包办。当然大型酒店集团，还会针对每个环节有更深入的应用，比如中央预订系统来处理各种渠道的预订订单、CRM 处理酒店会员关系管理、房价体系系统实现动态定价、房控系统实现客房资源利用最大化等等。但回归到核心，所有酒店都共有的核心，可以归纳为下面的核心业务流程：
核心业务流程具体描述如下：
-
客户选择预订渠道下订单：客户可以选择预订渠道预订酒店连锁集团下的任一酒店，包括从官网、 app、中介 OTA（如携程网等）、呼叫中心进行预订，也可以直接步入酒店在酒店前台当场进行预订。PMS 根据客户在某时间段里需要入住的酒店和房型，结合其可用房数量和当时的房间房价进行下预订单操作。预订单一旦生成，房态会发生变化，可用房数量也发生变化，最终结账的房价为当时下预订单时的房价。
-
住客入住接待：住客根据预订的时间来到预订的酒店办理入住。前台根据住客提供的身份证等信息办理入住，PMS 根据入住信息生成接待单，并将房卡制好发给住客。住客根据制好的房卡入住指定的房间。
-
住客服务接待：住客在入住期间，可以享受酒店提供的一系列礼宾服务和餐娱乐服务，比如叫醒服务、早餐服务等。每次服务接待都应在接待单里产生相应的接待服务信息；如果接待服务为收费项目时，比如餐饮服务，则需要同时进行账务处理，加入账单流水账中。
-
夜审：夜审主要是做入账对账及其核查。每次夜审都应该将住客房费和餐娱乐等费用进行核查，最终算入当日营业日业绩。只有夜审完成后，系统才能进行下一营业日的酒店营业操作。
-
住客退房：住客退房时，系统需要对住客在入住期间的所有服务及其费用进行核查结算，在满足退房条件的情况下，回收房卡，并更改房间房态。
-
客历归档：住客从入住到退房整个过程，默认将收集到的住客在期间的喜好和反馈存入住客档案中，供后续进行客户分析和客户个性化服务使用。
酒店的核心业务是稳定可扩展的，不随市场活动等外部日常运营业务而不断变化。因此 PMS 中，日常运营业务的变化，如市场活动对房价造成的影响，或餐娱乐服务对住客账单的影响等，都是与核心业务剥离弱化关联的，以此保证核心业务稳定沉淀的同时，系统仍然可以多变适应日常运营业务灵活多变的需要。
在理解酒店核心业务后，顺理成章可以得到酒店管理领域的核心子域——客房管理子域。这是因为酒店的所有核心业务都围绕着客房管理进行的。比如，预订房间时，最重要的是了解这家酒店的可用房信息及其相关房价、客人入住时需要关联房间并变更房态、酒店服务的收银账务是按房间来进行挂账买单的等等。以此为核心，通过 Bounded Context 关联各个相关子域。如下图所示：
领域中的界限上下文可以简单理解成一个子系统或组件模块，它放在哪个子域里最为合理是受到场景制约的。有时候，同样一个业务甚至同一个实体，会出现在不同的子域里，结合该子域的上下文来进行不同的描述。领域和界限上下文的划分并没有标准，它是依据每个人对特定业务不同程度的理解和抽象程度而不同的。评判一个领域模型是否合理，只能放到特定的业务背景和场景下才会相对客观。
最后根据上述战略建模的结果，进行领域模型上的战术建模。根据核心子域里的界限上下文及核心场景，抽象出领域实体及其关系，并用概念类图的方式呈现出来。这张领域模型图也有很多的画法，但最重要的是要让业务和技术等各方干系人都能理解这张图表达的涵义，以此形成统一的共识。领域模型图怎么画并不是关键，最关键的是明白领域模型要解决什么问题， 然后才能把这个问题毫无歧义的表述成一张图来凝结各方共识。战术建模得到的领域模型图，其关键就是识别出各类关键实体，以及它们之间的关系；而最终领域模型的验证反过来也是通过战略模型和核心业务场景流程来验证的。下图是酒店管理领域模型图示例。
思考总结
领域建模不是面向技术的一种纯软件设计方法，它是一种思维方式，我们采用它来搭建领域模型，以此弥补业务和代码之间的 Gap，促进团队合理的分工协作，同时也时刻真实的反映着我们所要解决的问题的变化，让我们构建的系统富有价值和生命力。
所以，领域模型的价值不在于它的设计优美﹐而在于它体现了系统的核心价值。那么什么是系统的核心价值？一个企业内部常用的费用报销系统和一个互联网的大型支付系统，它们本质的区别不是用了什么编程语言，也不是用了什么数据库，而是其提供的服务及其服务质量，也就是我们最开始所说的，它能解决的问题及解决的程度。