领域模型

在IT项目的构建中，沟通是一切协作的基础。但在系统的开发过程中，每个人都会用自己的方式解释需求和设计，为此，项目需要提供一个标准的词汇表来反映目前对需求空间的理解。领域建模是构建项目词汇表或项目中使用的词典的任务，但领域模型比项目词汇表更好，因为它以图形方式显示了所有这些不同的术语如何相互关联。实际上，它是一个简化的类图，在不同的类（领域对象）之间使用线条进行描绘，以显示它们如何相互关联。领域模型显示领域类之间的聚合和泛化关系（has-a和is-a关系）。项目的领域模型定义了范围，并形成了构建用例的基础。域模型还提供了一个常见的词汇表，以便能够在项目团队成员之间进行明确的沟通。 1. Collect application domain information 我们小组的课题是实现一个面向主题的搜索引擎，它的功能性需求包括 爬取网页获取内容 文本处理，建立索引库 分析关键字进行查询 2.Brainstorming 爬虫部分：爬取下载与主题相关的网页 文本处理：过滤网页，提取网页文本，建立索引 查询：分析关键字，检索文档 3.Classifying the domain concepts into 爬虫：自动登录、网页抓取、网页解析、存储 文本预处理：过滤网页、提取网页文本、分词 索引：建立索引、索引维护 查询：分析关键字、相关文档打分、排序 用户界面：搜索框，搜索结果展示 4.

一、什么是业务领域建模 　　 业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、为什么要进行领域建模 　　软件的世界里没有银弹，是用事务脚本还是领域模型没有对错之分，关键看是否合适。实际上，CQRS就是对事务脚本和领域模型两种模式的综合，因为对于Query和报表的场景，使用领域模型往往会把简单的事情弄复杂，此时完全可以用奥卡姆剃刀把领域层剃掉，直接访问Infrastructure。我个人也是坚决反对过度设计的，因此对于简单业务场景，我强力建议还是使用事务脚本，其优点是简单、直观、易上手。但对于复杂的业务场景，你再这么玩就不行了，因为一旦业务变得复杂，事务脚本就很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。 　　目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达

一、什么是业务领域建模 　　 这里引用百度百科的解释，业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、业务领域建模的设计步骤 　　领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。 　　1. 从业务描述中提取名词； 　　2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合； 　　3. 从业务实体集合中抽象业务模型，建立问题域的概念； 　　4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系 ； 三、业务领域建模的方法 　　四色建模法是由 Peter Coad 发明的一种建模方法，将抽象出来的对象分成四种原型： moment-interval：这种对象表示那些在某个时间点存在，或者会存在一段时间的，这样的对象往往表示了一次外界的请求，比如一次询价（Quotation），一次购买（Sale）

　　最近一段时间一直在做前中台的工作，也有一些感想。 　　目前我所接触到的是电商业务，无非是：商品、订单、促销、库存、履约、物流等，今天聊一聊供应链履约。 　　针对供应链而言，属于单后履约环节，大概分为：接单、拆单、定仓、推送订单信息至面单、发票等系统，最后下传至仓，开始物理履约，在此期间可能需要10个系统的几十次交互，系统是为完成用户需求或业务需求而建立的，那么如果在保障业务的前提下，深化领域模型，抽象系统逻辑，建立平台式服务是一个比较大的考验。 　　首先，我们要建立初步的领域模型，以上述履约流程为例，简单的需要调度系统、拆分系统、生产计划系统等，针对调度系统：不需要关心是何种订单（O2O、实体、医药等），更多的关系该订单的调度流程，如：需要【拆分、定仓、发票、面、仓】、【发票、面单、仓】等，根据业务需求将各个系统串联起来，它的最重要的领域即是：系统间交互信息，抓住这一点，抽象系统逻辑，无论是任何类型订单都可以通过调度系统串联起来。 　　其次，拆分系统，主要功能，将用户的订单拆单，拆分维度：商家、商品类型（医药、生鲜、家电等），那么对应的会生成多个订单，也会将原订单金额拆分，如果涉及到优惠（促销、满减、优惠券等），还需要做对应的金额逻辑，那么该系统的最重要的领域即是：拆分维度、促销模式，抓住这一点，抽象系统逻辑，不要关系何种业务接入，而关系该业务的拆分维度、促销模式

一、领域模型 　　　　显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。（类：表示业务概念，通常只包含重要属性，少甚至不包含操作；关联、泛化：表达概念之间的关系）， 　　总而言之：领域模型是描述业务领域（业务实体）的静态结构。 　　　　理论派认为，领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 　　　　实战派认为，领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。是需求分析人员与用户交流的有力工具，是彼此交流的语言。 二、建模 　　　　我的工程实践项目是基于文本理解的的聊天机器人（汽车领域）。 　　　　1.应用域信息 　　　　　　用户通过输入name，开始一个对话，输入汽车相关问题，从聊天机器人处获得回答，根据回答进行评价。 　　　　　　聊天机器人从用户处提取问题，送入模型进行计算，输出预测回答，根据评价进行学习。 　　　　2.重要的程序域及其属性 　　　　　　用户：name， 　　　　　　对话：记录，评价 　　　　　　聊天机器人：name，满意度 　　　　3.UML类图 　　　　　　 　　　　　　 来源： https:

分析和设计这两个术语经常出现在一起，人们也很常常混淆二者的含义，其他它们是完全不同的概念。分析是对需求（或问题）的调查研究。设计是已经定义的问题，构造一个逻辑上的解决方案。分析让我们知道面临着什么问题，设计告诉我们要如何去解决。这样看来，分析在设计之前，设计在分析之后。实际上人们对问题和解的认识是不断细化和深入的，因此在工作中往往是分析、设计、分析、设计不断循环，直到问题和解足够的“好”。什么是“好”呢？就是得到涉众的一致认可。面向对象分析和设计就是使用面向对象这个工具进行分析和设计。对象这个词在分析和设计阶段具有不同的含义。在分析阶段，对象是业务领域内的概念。在设计阶段，对象指软件对象，如模块、组件、类等。面向对象分析就是从使用者的视角出发，发现和描述业务领域内的概念，建立一个业务模型。面向对象分析的的主要工作内容是编写用例，并通过用例发现和建立领域模型。面向对象设计将业务领域概念映射为可以编码实现的软件对象。主要的工作包括分配软件对象职责、确定软件对象协作方式和详细设计软件类。在使用面向对象这个工具时，熟练地为对象分配职责是一项非常重要的能力。 为了展示面向对象分析和设计的工具和方法，我们来看一个简单的例子。 示例：骰子游戏。 玩家掷2个骰子，如果总点数为7则玩家获得胜利，否则输掉游戏。我们先从定义用例开始。用例（use case）是用户使用系统（或解决方案）的场景和情节。

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

引言 在讨论DDD分层架构的模式之前，我们先一起回顾一下DDD和分层架构的相关知识。 DDD DDD（Domain Driven Design，领域驱动设计）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。 UL（Ubiquitous Language，通用语言）是团队共享的语言，是DDD中最具威力的特性之一。不管你在团队中的角色如何，只要你是团队的一员，你都将使用UL。由于UL的重要性，所以需要让每个概念在各自的上下文中是清晰无歧义的，于是DDD在战略设计上提出了模式BC（Bounded Context，限界上下文）。UL和BC同时构成了DDD的两大支柱，并且它们是相辅相成的，即UL都有其确定的上下文含义，而BC中的每个概念都有唯一的含义。 一个业务领域划分成若干个BC，它们之间通过Context Map进行集成。BC是一个显式的边界，领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。 从广义上来讲，领域即是一个组织所做的事情以及其中所包含的一切，表示整个业务系统。由于“领域模型”包含了“领域”这个词，我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而

阿里巴巴Java开发手册中的DO、DTO、BO、AO、VO、POJO定义 分层领域模型规约： DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。 BO（ Business Object）：业务对象。 由Service层输出的封装业务逻辑的对象。 AO（ Application Object）：应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（ View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。 POJO（ Plain Ordinary Java Object）：在本手册中， POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。 Query：数据查询对象，各层接收上层的查询请求。 注意超过2个参数的查询封装，禁止使用Map类来传输。 领域模型命名规约： 数据对象：xxxDO，xxx即为数据表名。 数据传输对象：xxxDTO，xxx为业务领域相关的名称。 展示对象：xxxVO，xxx一般为网页名称。 POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。 DO和VO的 区别：

这篇文章讲的太好了，生怕以后被删掉。转到我博文列表里把-。- 正文： 开发者在刚开始尝试实现自己的微服务架构时往往会产生一系列问题 ： 微服务到底应该怎么划分？ 一个典型的微服务到底应该有多微？ 如果做了微服务设计，最后真的会有好处吗？ 回答上面的问题需要首先了解微服务设计的逻辑，科学的架构设计应该通过一些输入并逐步推导出结果，架构师要避免凭空设计和“拍脑门”的做法。 解耦的单体应用和微服务系统在逻辑上是一样的。对于服务拆分的逻辑来说，先设计高内聚低耦合的领域模型，再实现相应的分布式系统是一种比较合适的方式。 服务的划分有一些基本的方法和原则，通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥，无论是对遗留系统改造还是全新系统的架构都能游刃有余。 微服务拆分的几个阶段 在开始划分微服务之前，架构师需要在大脑中有一个重要的认识：微服务只是手段，不是目的。 微服务架构是为了让系统变得更容易拓展、更富有弹性。在把单体应用变成靠谱的微服务架构之前，单体系统的各个模块应该是合理、清晰地。 也就是说，从逻辑上单体系统和微服务没有区别，某种理想情况下微服务只是把单体系统的各个模块分开部署了而已（最近流行的monorepo把多个服务的代码仓库以模块的形式组织到了一起，证明了这一点）。 大量的实践教训告诉我们，混沌的微服务架构，比解耦良好的单体应用会带来更多麻烦。