领域模型

DMVP，全称DDD-MVP，是基于领域驱动设计（DDD）搭建的业务框架，整体设计符合DDD领域模型的规范，业务上达成了领域模型和代码的一一映射，技术上达成了高内聚低耦合的架构设计，开发人员不需要关注DDD框架设计，只需专心写业务逻辑即可，节约了人力成本。 DMVP框架特点： 1：通过页面简单配置，即可生成规范的DDD战术框架，只需在框架内实现业务逻辑即可。 2：代码和领域模型的统一对应，制定了领域模型和代码的对应规范，做到代码即领域模型，即业务。 3：框架由多年实战经验总结而成，实战过大型互联网分布式项目，期间框架历经多次改版。 4：框架设计思想和套路属于DDD实战先驱前列。 DMVP框架架构设计： DMVP框架使用： 目前使用比较简单，准备好业务的领域模型，在页面上进行录入，点击生成代码，即可生成标准DDD Maven工程，本地导入即可开发，使用步骤： 1：登陆框架首页，进行领域模型的录入。 2：点击生成代码按钮，后台生成代码框架后，浏览器自动下载，导入 idea，开始业务编码。 示例部分截图如下： 代码生成完成之后截图如下： 如何获得DMVP框架，扫描下方二维码即可获得，是收费的，付费之后你将获得4大特权： 1：整套框架的使用权限(非商用)，视频直播讲解DMVP，知识星球有问必答(晚上或周末集中作答，好的提问会有代码演示)。 2：多年DDD战略战术套路总结，每周一篇

1、引言 Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。 在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。 二、DDD中的模块 模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。 就拿电商系统来说，维护一个订单，需要收货地址、购买商品、订单信息。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。 这三个聚合就是一个模块，一个客户模块。通过定义一个order文件夹，来将相关联的领域对象组合起来。 通过以上的举例说明，我们可以看到每个模块都是相对独立的功能单元。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。 但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中

1、什么是Domain Modeling 　　业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务 用例 实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现： 图显示参与的业务角色和业务实体。活动图，其中泳道显示业务角色的职责，而对象流显示如何在 工作流程 中使用业务实体。 序列图描述业务角色和业务主角之间交互的详细情况，并显示如何在业务用例执行过程中访问业务实体。 业务对象模型将结构的概念和行为的概念结合了起来。 它是一个纽带工件，用于对业务关系进行清晰的表述，表述方式与软件开发人员的思考方式类似，同时仍保留一些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。 它探索业务领域知识的本质，所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上来。 它是一种确定需求的方法

一、业务领域建模的概念 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。 业务对象模型（领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、业务领域建模的意义 建立领域模型的好处： 1，通过建立领域模型能够从现实的问题域中找到最有代表性的概念对象 2，并发现出其中的类和类之间的关系，因为所捕捉出的类是反馈问题域本质内容的信息。 经典的面向对象的分析或调研的步骤，是把一个相关的领域，分解为单个领域类或者对象（是一个我们能够理解的概念）。 领域模型是领域类或者是我们感兴趣的现实对象的可视化表示。 它们也被称之为：概念模型、领域对象模型、分析对象模型等。 在UML中，领域模型是不定义操作（方法）的一组类图来说明，它主要表达： 1） 领域对象或者领域类 2） 领域类之间的关联 3） 领域类的属性 属性用以表达对象的状态。 三

业务领域建模的概念 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务领域建模的原因 业务建模在ERP工程中被着重强调，而且ERP中的BPR已经成为一门独立的学科。不仅如此，即便是在普通的信息系统中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上，可能大家会不理解，如果你只是为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。这里有两点原因，一是企业原有的 业务模式 在以人为主的环境中可能运行的很好，可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入，所以流程必须经过调整以适应计算机;第二个原因是上面已经提到过的避免产生部门级的，部分功能区域的应用系统。 在 RUP 中，业务建模被作为下游流程的输入重点强调:业务模型是需求 工作流 程的一种重要输入，用来了解对系统的需求。(RUP) 业务领域建模的步骤 领域模型设计是需求分析的 关键步骤 。它帮助用户及需求分析人员建立业务概念

业务领域建模的概念 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务领域建模的原因 业务建模在ERP工程中被着重强调，而且ERP中的BPR已经成为一门独立的学科。不仅如此，即便是在普通的信息系统中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上，可能大家会不理解，如果你只是为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。这里有两点原因，一是企业原有的 业务模式 在以人为主的环境中可能运行的很好，可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入，所以流程必须经过调整以适应计算机;第二个原因是上面已经提到过的避免产生部门级的，部分功能区域的应用系统。 在 RUP 中，业务建模被作为下游流程的输入重点强调:业务模型是需求 工作流 程的一种重要输入，用来了解对系统的需求。(RUP) 业务领域建模的步骤 领域模型设计是需求分析的 关键步骤 。它帮助用户及需求分析人员建立业务概念

1.什么是领域建模 领域建模是建造领域模型的过程，而领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。领域模型是说明问题域（现实世界中系统所要解决问题的领域为“问题域”，如“银行业务”属于“银行的问题域”。）里（对建模者来说）有意义的领域类，它是面向对象分序的时候要创建的最重要的工作（必须说明，用例虽然也是一个重要的分析工作，但它并不是面向对象的，它是强调的概念的过程视图）。 2.如何领域建模 ♦ 1) Collect application domain information – focus on the functional requirements – also consider other requirements and documents ♦ 2) Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other ♦ 3) Classifying the domain concepts into: – classes –

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

领域建模简介 　　领域模型（domain model）是对领域内的概念类或现实世界中的可视化表示。领域模型也叫做概念模型、领域对象模型和分析对象模型。领域模型和类都是对现实中的实体的描述，但是它们之间是有区别的，领域模型是对现实世界概念类的表示，不是软件对象的表示。它不用来描述软件类、架构或者软件对象。 结合工程实践建模 　　我的工程实践是做一款类似于facerig的软件，可以通过摄像头等设备实施捕捉到用户的面部，输入为视频流，并且实时映射到卡通模型上，并且将模型覆盖到人脸，达到换脸的效果。 1、Collect application domain information 首先收集系统主要业务的功能性需求与非功能性需求，用户需求。 　　功能性需求 （1）设计并训练好的模型，可以对输入的视频流处理实时捕捉人脸特征点； （2）将特征点映射到模型上，使其与人脸变化同步，并且覆盖到视频流中的人脸； （3）收集和响应用户的数据和行为。 2、Brainstorming （1）列出重要的应用程序域概念 （2）列出它们的属性 （3）列出它们之间的关系 3、Classifying the domain concepts （1）类 （2）属性/属性值 （3）关系：association, inheritance, aggregation 4、Document result using UML

一、业务领域建模的要求 1.收集应用领域信息 -关注功能需求-也考虑其他需求和文档 2.头脑风暴 -列出重要的应用领域概念-列出它们的属性/属性-列出它们之间的关系 3.将业务领域概念分类 -类-属性/属性值-关系 4.关联、继承、聚合 阐述了UML类图对结果的文档化 二、领域建模的十大方法 1.关注现实世界（问题领域）对象。 创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。 2.使用泛化（is-a）和聚合（has-a）关系来显示对象如何相互关联。 随着时间的推移，会使用新的领域类别来识别领域模型。会注意到他们之间的联系（或关联） - 例如，书评属于书，采购订单（purchase order）和信用卡（credit card）是两种，因为它们都是付款类型。 第一个关系（书评属于一本书）被称为聚合（has-a，因为一本书都会有一书评）。第二个关系（采购订单和信用卡都是付款类型）被称为泛化（is-a，因为采购订单是付款类型）。图2-3显示了这些概念的说明。 这些所谓的一般关系是领域模型中最重要的关系