精华内容
下载资源
问答
  • 领域模型

    千次阅读 2019-06-06 17:51:57
    领域模型就是其中之一,网络上搜索到关于领域模型的知识应该是有两种,一种是来源于最初的传统软件开发过程,一种来源于领域驱动设计(DDD),这两者很容易混淆。以下是我对领域模型这个概念的一些理解。 1. 领域...

    背景

    UML比较难学,主要是其本身很复杂并且涉及到大量的概念名词。领域模型就是其中之一,网络上搜索到关于领域模型的知识应该是有两种,一种是来源于最初的传统软件开发过程,一种来源于领域驱动设计(DDD),这两者很容易混淆。以下是我对领域模型这个概念的一些理解。

    1. 领域模型是什么?

    理论派观点:

    • Domain Model是一个商业建模范畴概念,即使一个企业不开发软件,也具备其业务模型;
    • 所有同行企业,其业务模型必定有非常大的共性和内在的规律性。
    • 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型,这个模型称之为“领域模型”。

    实战派观点:

    • 领域模型是一个分析模型,帮助系统分析人员、用户认识现实业务的工具,描述的是业务中涉及到的实体及其相互之间的关系,它是需求分析的产物,与问题域相关。
    • 是需求分析人员与用户交流的有力工具,是彼此交流的语言。

    理论派

    领域模型是一种特殊的业务模型,它分析范围是整个行业,抽象出行业里共性和内在规律性的业务,比业务模型更加抽象,它不属于软件开发范畴的概念,与软件开发无关。

    实战派

    领域模型是一种分析模型,在软件开发过程分析阶段用于分析如何满足系统功能性需求,属于软件开发范畴,在UML中主要使用类图来描述领域模型。

    业务模型是业务建模的输出物,业务建模研究的对象是公司或者组织,业务建模属于软件开发过程中的初始阶段。

    软件开发过程:业务建模、需求、分析、设计。

    在软件开发过程中我们接触到的领域模型属于实战派

    2. 领域模型作用

    理论派

    领域模型是一种特殊业务模型,作用都是:

    • 帮助分析理解复杂业务领域问题。
    • 行业内沟通、交流。

    实战派
    领域模型作用:

    • 分析如何满足系统功能性需求。
    • 指导项目后续的系统设计。

    业务模型作用:

    • 帮助系统需求人员理解客户公司业务,下一阶段做需求以业务模型为输入得到系统用例。

    3. 领域模型与业务模型的区别

    理论派

    领域模型是一种特殊的业务模型,所以具备业务模型的所有特点,但是比业务模型更抽象、更通用。

    实战派

    • 产出阶段不同

    业务模型是在软件开发过程中业务建模阶段产生,领域模型是在分析阶段产生。

    • 作用不同

    业务模型是系统需求人员理解客户公司业务的产物,下一阶段需求将以业务模型为输入得到系统需求。

    领域模型是系统分析人员分析如何满足系统功能性需求的产物。下一阶段设计将以领域模型为输入。

    “实战派”举例说明:

    当接到项目,需要做一个酒店预订系统,首先进行业务建模,了解客户公司酒店管理的相关业务,这就会产出业务模型,此时业务模型里除了酒店预订这个业务环节还包括其他与酒店预订同层次的业务环节。

    接下来将视线聚焦到酒店预订,改进已有流程得到酒店预订系统需求,即系统用例和需求规约。

    接下来通过分析系统用例和需求规约,分析如何满足酒店管理系统功能性需求,从而得到领域模型。

    "理论派"和“实战派”的领域模型是两个范畴的东西,若没有分清肯定会引起理解混乱。

    4. 另一种“领域模型” - 领域驱动设计(Domain-Driven Design)

    还有一种“领域模型”,它出自于Eric Evans的“Domain-Driven Design”简称DDD,也就是“领域驱动设计”,DDD是一套综合软件系统分析和设计的面向对象建模方法,所以要明确区分这两种领域模型。失血模型、贫血模型、充血模型这类概念都属于DDD范畴的“领域模型”。

    4.1 两种领域模型的区别

    本文中“领域模型”都代表领域驱动设计中的领域模型。

    1. 解决的核心问题不同

    正如前文所说的,领域模型是一个用于分析业务的分析模型,在实际项目中要解决的核心问题是:

    • 如何满足待开发系统业务功能需求。

    而“领域模型”是综合分析与设计的模型,要解决的核心问题是:

    • 保证系统设计能满足项目多变的需求。

    在传统的软件开发流程中,分析(系统需求分析)和设计(系统设计)被划分为两个阶段,分别对应国家“系统分析师” 和“系统设计师” 两种职称,这种割裂的结果导致,“系统设计师”要基于需求分析的结果做系统设计后才能进行编码,这中间会存在信息上的丢失或失真,并且实际过程中业务需求会变(可能是外界环境的变化或者对业务有更深的理解引起),就更容易引起系统设计与项目需求脱节。Eric Evans提出的DDD思想就是想解决这样问题。

    2. 领域不同

    领域模型是业务分析模型,分析的是系统功能性需求所出核心域的业务,软件系统只是实现业务的方式而非业务的一部分(提供IaaS服务的公司除外),不会考虑系统设计IT领域里问题。

    “领域模型”是综合分析和设计的模型,涉及到系统设计,需要思考系统的边界,故该模型所分析设计的领域是综合了业务领域和IT领域。

    以酒店预订系统为列,其业务描述如下

    • 所有用户都可通过酒店订房管理系统查看酒店客房信息
    • 用户如需预定需先注册成会员

    以上涉及到两个对象:用户、会员。

    若做业务分析,第一段描述中的“用户”可能就需要考虑,它可能是游客、咨询者的业务含义。

    若要考虑系统设计,第一段描述中的“用户”可能就会忽略,即不在系统边界范围内。

    3. 使用的阶段和岗位不同

    领域模型是分析业务的分析模型,在实际项目中主要由系统分析师在分析阶段中使用。

    DDD的“领域模型”是综合分析、设计的模型,在实际项目中横跨分析和设计两个阶段,岗位需要具备“系统分析师”和“系统设计师”的综合能力。

    4. 包含的内容不同

    领域模型主要内容:

    • 业务实体
    • 业务实体之间关系

    “领域模型”主要内容:

    • 业务实体
    • 业务实体属性
    • 业务实体之间关系
    • 服务
    • 服务与实体之间的关系

    5. 总结

    领域模型分理论派和实战派,理论派属于商业范畴不属于软件开发范畴,软件开发过程不用理会理论派,切忌相互混淆。

    实战派认为领域模型是一种分析模型,用于分析理解复杂业务领域问题,具体到软件开发过程中就是在分析阶段分析如何满足系统功能性需求。

    同时在软件开发范畴还有来自于DDD的“领域模型”,这是一种综合分析与设计一体的模型,注重系统设计与需求分析、系统需求的衔接,设计出系统与需求有较好的一致性,针对合理的需求变化也更具有良好的扩展性。

    6. 参考文章

    展开全文
  • 领域模型设计

    千次阅读 多人点赞 2020-07-27 14:48:11
    领域模型设计介绍领域模型设计一、前言二、领域与对象三、复杂领域设计原则四、领域驱动设计和实施五、领域划分六、逻辑架构设计七、DDD软件分层设计 领域模型设计 一、前言 现代微服务系统一般涉及的业务流程多,...

    领域模型设计

    一、前言

    现代微服务系统一般涉及的业务流程多,系统交互场景丰富,为了合理切分业务领域,恰当定义业务边界,并以此开发出“高内聚,低耦合”的代码,采用DDD(Domain-Driven Design)领域驱动设计思想就能很好地实现这个目标,根据业务领域合理分层软件架构,让系统拓展性更强,结构更清晰,更灵活,复用程度更高,轻松应对各种复杂的业务需求。

    二、领域与对象

    1.什么是对象
    对象在面向对象定义之中,也规定了一些基本的特征:
    (1)封装:保护内部的操作不被破坏;
    (2)继承:在原本的基础之上继续进行扩充;
    (3)多态:在一个指定的范围之内进行概念的转换。
    2.什么是领域驱动设计
    领域驱动设计(Domain-Driven Design 简称DDD),是一套综合软件系统分析和设计的面对对象建模方法,采用领域模型概念,统一分析和设计编程,使软件能够更加灵活快速地跟随需求变化。
    领域驱动设计的核心在领域模型,领域模型的核心在业务知识。
    3.什么是领域对象
    领域对象(Domain Object)分为实体对象(也称聚合根)和值对象。
    实体对象是具有生命周期、有唯一标识、可以通过唯一标识判断相等性、有增改删查操作、可记录状态的对象。
    值对象是指起描述作用,无唯一标识、只能通过属性判断是否相等、即时创建、用完就回收的不可变对象。值对象必须通过实体对象进行操作。
    4.领域模型中的实体类关系
    领域模型的实体类分为视图对象VO(View Object)、数据传输对象DTO(Data Transfer Object)、领域对象DO(Domain Object)、持久化对象PO(Persistent Object)四种类型,各种实体用于不同业务层次之间的交互,并在各层次间实现转化,如下图所示:
    在这里插入图片描述

    5.对象和领域的关系
    领域是更大的对象,是可以直接产生业务价值的模型,只包含多对象的行为整合,不包含对象的属性,从而实现领域的行为共享。
    领域模型是对业务需求的一种抽象,表达了领域概念、领域规则以及领域概念之间的关系。一个好的领域模型是对统一语言的可视化表示,通过它可以减少需求沟通可能出现的歧义;通过提炼领域知识,并运用抽象的领域模型去表达,就可以达到对领域逻辑的化繁为简。模型是封装,实现了对业务细节的隐藏;模型是抽象,提取了领域知识的共同特征,保留了面对变化时能够良好拓展的可能性。
    领域模型以可视化的方式清晰地表达了业务含义,我们可以根据这个模型来指导后面的程序设计与编码实现。当增加新的需求或者需求发生变化时,我们能够敏锐地捕捉到现有模型的不匹配之处,并对其进行更新。领域模型传递了知识,可以作为交流的载体,符合人们的心智模型,有利于让开发人员从纷繁复杂的业务中解脱出来。

    在这里插入图片描述

    三、复杂领域设计原则

    1.拆分子域建立领域模型
    根据业务特点考虑流程节点或功能模块边界因素,按领域逐级分解成大小合适的子域,针对子域进行事件风暴,记录领域对象,初步确定各级子域的领域模型。
    2.领域模型微调
    梳理领域内所有子域的领域模型,对各子域模型进行微调,这个过程重点考虑不同聚合对象的重新组合,同步需要考虑子域里对象的聚合边界、服务以及事件之间的依赖关系,确定最终的领域模型。
    3.微服务设计和拆解
    根据领域模型的边界和微服务的拆分原则,完成微服务的拆分和设计。

    四、领域驱动设计和实施

    1.步骤一、事件风暴
    (1)场景分析
    根据不同角色和场景,全面梳理从前端操作到后端业务逻辑之间发生的所有操作、命令、领域事件以及外部依赖信息。
    (2)领域建模
    领域建模是一个收敛的过程。过程分为三步:第一步根据场景分析中的操作集合定义领域实体;第二步根据领域实体业务关联性定义聚合;第三步根据业务和语义边界等因素,定义领域模型。
    (3)微服务设计和拆分
    综合考虑职责单一性、性能、版本发布频率、团队沟通效率、技术异构等因素,合理设计和拆分微服务。
    2.步骤二、领域对象服务矩阵
    将事件风暴产生的领域对象按照各自所在的微服务进行分类,定义每个领域对象在微服务中的层、领域类型和依赖的领域对象,主要是为了确定实体、方法、服务等领域对象在架构中的位置以及对象之间的依赖关系,形成服务矩阵,细化了领域对象之间的关系,补充了事件风暴过程中可能遗漏的细节。
    3.步骤三、领域模型服务架构
    根据领域模型中领域对象的属性和服务矩阵,设计符合领域模型的技术架构,架构要能清晰地体现微服务实体间的联系,各层级之间的关系,以及服务组合和编排的关系。
    4.步骤四、代码模型设计
    根据DDD技术架构设计,搭建微服务架构体系,定义各层的微服务工程,各层的领域对象所在的包、类、方法、接口,领域中一个聚合对应一个聚合包。

    五、领域划分

    领域是自上而下的划分,不仅需要在这些相关联的领域有着极其丰富的经验,脑海中有着清晰且成熟的领域模型图。
    而自下而上,也就是本文所讲的,主要思想是从需求出发,划分出实体后,对实体进行归类,最终提炼出领域。
    1)对需求进行充分分析,提炼通用语言,从通用语言中抽象出实体
    我们首先对需求进行充分分析,提炼通用语言,从通用语言中抽象出实体。
    2)按照职责相似度,对实体进行归类,抽象出领域
    通过上面的步骤,我们得到了很多实体,然后按照职责的相似度对实体进行归类,相似度高的为一类,每一类给他们起一个名字,这就是领域。

    六、逻辑架构设计

    在这里插入图片描述
    逻辑架构图主要分为业务层、领域层、数据持久层,其他微服务模块通过zuul网关区分不同业务标识对应的服务路由到业务层,然后业务层通过组合、编排领域层服务,实现业务流程,领域服务操作领域对象(聚合根)和值对象,实现领域对象的属性修改和一系列领域对象行为,调用基础设施层完成完成一系列基础服务和数据库原子操作,实现数据持久化。

    七、DDD软件分层设计

    1.分层概述
    (1)业务层system-xxx-application:组合与编排各领域服务,实现业务流程。
    (2)springcloud微服务接口jar包system-xxx-feignclient:暴露微服务领域接口。
    (3)领域层system-xxx-domain:单领域服务实现。
    (4)领域接口jar包 system-xxx-domain-api:定义领域对象和操作接口。
    (5)基础设施层system-xxx-infrastructure:数据存储与处理。
    (6)公共服务 system-domain-common-xxx:公共配置、工具类。
    (7)system-domain-data-config:Spring容器扫描配置
    2.分层结构图
    总体上分为业务层、领域层、基础设施层,前端通过restful方式请求业务层,业务层通过Spring Cloud的FeignClient接口实现远程调用领域层的微服务,领域层通过自定义Spring容器扫描配置注入不同数据源的组件,从而实现多数据源的操作。
    在这里插入图片描述

    3.层级maven依赖关系
    在这里插入图片描述

    展开全文
  • 领域模型编程

    2018-11-21 15:53:19
    领域模型编程什么是领域模型聚合根聚合根和实体、值对象的区别实体和值对象的区别聚合根和实体、值对象的区别充血模型、贫血模型基于领域模型的开发简化的领域模型开发UML图 什么是领域模型 业务对象模型(也叫领域...

    什么是领域模型

    业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。它专注在业务领域的逻辑抽象,而不是技术实现。

    聚合根

    基于领域模型的设计,先根据业务模型拆分成各个大模块(对应于一个子项目),然后根据大模块拆分成小模块(对应于一个Module),可能会拆分成更小的模块(对应于Package)。业务领域中的某个具体的概念,对应的就是一个聚合。聚合Aggregate就是一组相关对象的集合。用于表示某个聚合的主对象就是聚合根。(下面用聚合根指代聚合)

    聚合根和实体、值对象的区别

    实体对应的是一个类,对应于数据库中是一张表。值对象(Value Object,Vo),对应于一个类,也可以对应于数据库中的一张表,也可以不对应表。

    实体和值对象的区别

    两个实体,他们的属性都一样,但他们还是不同的实体。
    两个值对象,他们的属性都一样,则他们是同一个值对象。
    简单来讲,实体必须有id,值对象可以没有id。

    聚合根和实体、值对象的区别

    聚合根和实体、值对象是一对多的关系。
    当一个实体已经能表达业务层的一个概念的时候,这个聚合根就只包含一个实体。
    当一个聚合根需要n个实体和n个值对象表达的时候,这个聚合根就包含这些实体和值对象。

    充血模型、贫血模型

    实体类中只包含get和set方法,这样的实体类表达叫贫血模型。
    实体类中不仅包含get和set方法,还包含实体对应的业务逻辑,这样的实体类表达叫充血模型。

    领域模型使用的是充血模型,具体的业务逻辑写在聚合根的类中。

    基于领域模型的开发

    假设各个聚合根已经分析出来。
    先完成聚合根的类的开发。
    聚合根–>Aggregate

    然后再完成聚合根的数据库存储操作:
    聚合根的数据库存储操作–>Resposity

    在此基础上,完成service层和controller层。

    简化的领域模型开发

    标准的Resposity和Aggregate的开发会建比较多的resposity和aggregate类,并且使用的是充血模型,跟平常的贫血的web开发模型差别比较大。
    为了让刚接触领域模型的开发人员逐渐适应这种开发模式,在实践中摸索出了一套简化的贫血式的领域开发模式。

    假设聚合根C,包含实体A和B。

    数据库Dao层:ADao、BDao

    新建一个logic层,包含A和B的业务逻辑,假设叫ALogic和BLogic

    标准的领域模式是:
    C c = CResposity.get(id);
    c.业务处理()
    CResposity.save©

    其中:
    CResposity.save(){
    ADao.save()
    BDao.save()
    }

    简化的领域模型:
    A a = ADao.get();
    B b = BDao.get();

    Alogic.业务处理
    BLogic.业务处理

    ADao.save(a)
    BDao.save(b)

    如果系统比较简单,聚合根很清楚,可以用简化的开发模式。如果系统比较复杂,聚合根很多,建议使用标准的领域模型来开发。

    UML图

    一般的web开发是从表设计开始,然后写Dao、service和Controller。领域模型开发先从聚合根开始,然后再写Dao、Service和Controller。

    在简化模型中,是先从logic层开始开发。
    如何开发logic层,一般是先从画出设计图开始。

    常用的设计用的uml图:
    状态机图:
    节点表示状态,节点间的线条表示状态间的转换,一般每条线条都是一个方法。如果聚合根有状态,默认用状态机图。

    协作图:
    节点表示实体或聚合根,节点间的线条表示节点间的交互。强调节点的拓扑结构。

    时序图:
    节点表示实体或聚合根,节点间的线条表示节点间的交互和调用。强调行为的时间次序。

    活动图(流程图):
    节点表示动作,节点间的线条表示动作的次序。动作的顺序。

    选择哪种UML图的一般建议:
    原则是如果对某一个逻辑或者调用关系不清晰,就需要先画图来搞清楚逻辑。
    1、如果有状态,默认用状态机图。
    2、如果是实体或聚合根间交互,如果时间次序要求不强,而且实体数比较多,可以使用协作图。如果强调时间次序,可以使用时序图。
    3、如果是某个方法或service内的处理逻辑(顺序、判断、循环),可以使用活动图。

    一般的要求是,先画图确认设计,再实现业务逻辑(logic层)。实现完业务逻辑后,再进行其他层的开发。

    展开全文
  • 一、分层领域模型规约 DO(Data Object):与数据库表结构一一对应,通过DAO层向上传输数据源对象。 DTO(Data Transfer Object):数据传输对象,Service或Manager向外传输的对象。 BO(Business Object):业务...

    一、分层领域模型规约

    DO(Data Object):与数据库表结构一一对应,通过DAO层向上传输数据源对象。
    DTO(Data Transfer Object):数据传输对象,Service或Manager向外传输的对象。
    BO(Business Object):业务对象。由Service层输出的封装业务逻辑的对象。
    AO(Application Object):应用对象。在Web层与Service层之间抽象的复用对象模型,极为贴近展示层,复用度不高。
    VO(View Object):显示层对象,通常是Web向模板渲染引擎层传输的对象。
    Query:数据查询对象,各层接收上层的查询请求。注意超过2个参数的查询封装,禁止使用Map类来传输。

    二、领域模型命名规约

    1) 数据对象:xxxDo,xxx即为数据表名。

    2) 数据传输对象:xxxDto xxxBo,xxx为业务领域相关的名称。

    3) 展示对象:xxxVo,xxx一般为网页名称。

    4) POJO是DO/DTO/BO/VO的统称,禁止命名成xxxPOJO。

     

    整个web 的流程中的过程是:

     

    非常简单的一个图.

     

    最近在看<人月神话>,这书还不错, 旁边一个卖保险的哥们看到这本书的名字,以为我在看小说, 问我是不是想到月亮上去做神仙.哈哈哈

    2019年6月10日19:04:49

     

     

    2019年6月11日16:31:18  更新:

    今天看到肥朝的博客中一段话 , 就是下面的一段,  感触比较深, 其实有时候看起来蛮复杂的事情又很简单, 简单的事情又很难以做到. 拿我来说, 晚上跑步,写博客啊(虽然有些比较浅显, 已经很费时间了, 写一些深入的东西, 需要从原理写到事件, 再提高, 真的很需要时间), 表面上确实能够锻炼身体, 也能总结自己 , 但这些都是附带的, 我就想知道我能坚持多久,  一个人的毅力能够有多大.  佛有说大智慧, 大毅力, 大智慧是什么我可能无法知道了, 但是大毅力我觉得可能会知道吧


     

     

     

    展开全文
  • 领域模型详解

    万次阅读 多人点赞 2018-06-19 18:24:26
    领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系,是真实世界各个事物的表示(现实世界的...
  • 领域模型介绍

    千次阅读 2019-05-30 09:44:19
    领域模型就是其中之一,网络上搜索到关于领域模型的知识应该是有两种,一种是来源于最初的传统软件开发过程,一种来源于领域驱动设计(DDD),这两者很容易混淆。以下是我对领域模型这个概念的一些理解。 1. 领域...
  • 一、领域模型  领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。  领域模型从业务...
  • 浅谈领域模型

    2020-10-05 09:04:32
    |0x00 领域模型是什么 领域模型是什么?一句话:“经济基础决定上层建筑”中的“经济基础”,是帮助理解复杂业务领域问题的基石。 有人说:“领域模型是一个商业概念,同行业的企业,一定有内在的共性,是帮助系统...
  • 建立领域模型

    千次阅读 2016-05-25 17:15:25
    简介领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。
  • 贫血领域模型

    2017-08-15 10:04:51
    贫血领域模型是一个存在已久的反模式,目前仍有许多拥趸者。一次我和Eric Evans聊天谈到它时,都觉得这个模型似乎越来越流行了。作为领域模型的推广者,我们觉得这不是一件好事。
  • 贫血模型即是事务脚本模式,充血模型即是领域模型模式。 贫血模型 最早广泛应用是源自于EJB2,最强盛时期则是由Spring创造,把“行为”(也称为逻辑、过程)和“状态”(可理解为数据,对应到语言就是对象成员变量)...
  • Java领域模型

    千次阅读 2018-04-18 16:25:22
    领域模型中的实体类可细分为4种类型:VO、DTO、DO、PO。PO:持久化对象,表示持久层的数据结构;DO : 领域对象,即业务实体对象;DTO : 数据传输对象,用于展示层与服务层之间的数据传输对象,因此可以将DTO看成一个...
  • 领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点: 领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是...
  • 领域模型、贫血模型、充血模型概念总结

    万次阅读 热门讨论 2015-04-28 16:45:41
    1. 领域模型  领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。 ...
  • 领域模型驱动设计

    千次阅读 2018-12-06 09:26:26
    软件开发可以干什么: 真是世界业务流程的自动化 解决现实问题 领域(Domain)   领域建模: ...1.将领域模型相关的代码集中到一个层中,把它从用户界面、应用和基础设施代码中分隔开来 2.释放领域对...
  • 领域模型,领域对象是从数据模型生成还是从数据库生成,没有币,求大神指点

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 38,153
精华内容 15,261
关键字:

领域模型