通信工程企业网站建设,ghostwin8网站奖别人做,电商一年可以赚多少钱,合肥网站维护一、背景
常见的软件开发方式是拿到产品需求后#xff0c;直接考虑数据库中表应该如何设计#xff0c;这种方式已经将设计与业务需求脱节#xff0c;而更多的是直接考虑应该如何实现了#xff0c;这有点本末倒置。而DDD是从领域(问题域)为出发点进行的设计方法。
领域驱动…一、背景
常见的软件开发方式是拿到产品需求后直接考虑数据库中表应该如何设计这种方式已经将设计与业务需求脱节而更多的是直接考虑应该如何实现了这有点本末倒置。而DDD是从领域(问题域)为出发点进行的设计方法。
领域驱动设计的核心是“领域”从一开始就要让团队走到正确的点上。当我们组建好了团队之后应该从哪里开始不是UI原型设计不是架构设计不是设计数据库这些事情重要却非最高优先级。用正确的方法做正确的事情运用领域驱动设计就是要先识别问题域进而为团队提炼达成共识的领域知识。要做到这一点离不开团队各个角色的沟通与协作。
二、DDD 要解决的两个核心问题 1. 业务架构 如何合理的设计 2. 如何使系统架构域业务架构保持一致并具备可持续的扩展 领域驱动的设计目标有效建模并运⽤用领域模型驱动团队进⾏行行沟通分析、设计及开发。 三、领域驱设计的核心思想
1、模型与现实业务的统一 ・模型和程序设计的核心相互影响。正是模型与实现之间的紧密联系才使模型变得有⽤ 并确保我们在模型中所进行的分析能够转化为最终程序。 ・模型与实现之间的这种紧密结合 在维护和后续开发期间也会很有用因为我们可以基于对模型的理理解来解释代码。 2、统一业务和技术语言 ・模型是团队所有成员使用的通⽤语⾔的中枢。由于模型与实现之间的关联开发人员可 以⽤该语⾔来讨论程序。 ・他们可以在无需翻译的情况下与领域专家进行沟通。⽽且由于该语言是基于模型的因此我们可借助自然语⾔对模型本身进行精化。 3、团队的持续学习消化知识系统持续的发展 模型是浓缩的知识。模型是团队一致认同的领域知识的组织⽅式 和重要元素的区分⽅ 式。透过我们如何选择术语、分解概念以及将概念联系起来模型纪录了我们看待领域的⽅式。 当开发⼈员和领域专家在将信息组织为模型时这一共同的语⾔ (模型) 能够促使 他们⾼效地协作。
四、DDD设计步骤
4.1 基本概念
(1)实体(Entity)一个由它的标识定义的对象叫做实体。通常实体具备唯一ID能够被持久化具有业务逻辑对应现实世界业务对象。
(2)值对象(Value Object)一个没有概念上标识符描述一个领域方面的对象这些对象是用来表示临时的事物或者可以认为值对象是实体的属性这些属性没有特性标识但同时表达了领域中某类含义的概念。通常值对象不具有唯一ID由对象的属性描述可以用来传递参数或对实体进行补充描述。
(3)服务(Service)提供的操作是它提供给使用它的客户端并突出领域对象的关系。所有的Service只负责协调并委派业务逻辑给领域对象进行处理其本身并真正实现业务逻辑绝大部分的业务逻辑都由领域对象承载和实现了。Service可与多种组件进行交互当一个领域操作被视为一个重要的领域概念一般就作为领域服务服务是无状态的。
(4)聚合(Aggregate)用来定义领域对象所有权和边界的领域模式是用来帮助简化模型对象间的关系。通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚并避免了错综复杂的难以维护的对象关系网的形成。
(5)聚合根(Aggregate Root)每个聚合都有一个根对象(聚合根实体)从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用但是外部对象只能引用根对象实体。只有聚合根才能使用仓储库直接查询如果根实体被删除聚合内部的其它对象也将被删除。
(6)仓储(Repository)是用来管理实体的集合仓储里面存放的对象一定是聚合原因是domain是以聚合的概念来划分边界的聚合作为一个整体概念要么一起被取出来要么一起被删除。外部访问不会单独对某个聚合内的子对象进行单独操作。因此我们只对聚合设计仓储。
(7)工厂(Factory)用来封装创建一个复杂对象尤其是聚合时所需的知识是将创建对象的细节隐藏起来。如客户传递给工厂一些简单的参数然后工厂可以在内部创建一个复杂的领域对象然后返回给客户。
(8)领域事件(Domain Event)是将领域对象从对repository或service的依赖中解脱出来避免让领域对象对这些设施产生直接依赖。领域事件的触发点在领域模型(domain model)中。就是当领域对象的业务方法需要依赖到这些对象时就发出一个事件这个事件会被相应的对象监听到并做出处理。 4.2 描述需求
需求描述要点
(1)在对业务充分沟通和深入理解的基础上从业务描述中提取名词作为关键字
(2)对关键需求点描述的格式应尽量表述为“用户需求场景操作对象”并在团队之间达成共识
(3)从提取出来的名词中总结实体形成问题域
(4)需求描述格式不限可以用UML提供的方法和图例进行领域模型设计、确定模型之间的关系也可以用其他传统方式目标是团队成员理解一致即可。
用UML方法描述需求举例 4.3、划分领域
(1)领域(Domain)领域就是问题域一个领域可以拆分为多个子领域(Sub Domain)。
(2)核心子域(Core Domain)子领域中最核心的叫核心子域团队的核心资源应该用在核心子域上因为它是产品成败的关键。
(3)支撑子域(Supporting Subdomain)除了Core Domain外其他的是支撑子域。
(4)通用子域(Generic Subdomain)有些支撑子域比较特殊因为它解决的是一类通用问题这类子域我们叫做通用子域。 通用子域对应的限界上下文通常会跨多个子域多个子领域有时会有相交的部分称作共享内核体现到代码上就是同一份代码在多个领域模型中复用领域示意图如下 4.4、限界上下文
限界上下文划分依据
(1)围绕语言定义边界利用语义相关性和功能相关性对用例归类
(2)与业务能力保持一致避免限界上下文工作边界过大
(3)围绕团队创建上下文从技术角度考虑重用和变化的应对、遗留系统的集成。
美团抽奖平台上下文映射如下 4.5、战术建模
(1)实体(Entity)当一个对象由其标识(而不是属性)区分时这种对象称为实体
(2)值对象(Value Object)当一个对象用于对事务进行描述而没有唯一标识时它被称作值对象
(3)聚合根(Aggregate Root)聚合是一组相关对象的集合作为一个整体被外界访问聚合根是这个聚合的根节点
(4)领域事件领域事件是对领域内发生的活动进行的建模。
一个手绘的简易建模如下 6、用DDD写需求规格说明书
总结利用领域模型产出需求规格说明书的一般步骤
(1)需求的理解和描述抽取提炼关键字
(2)根据需求划分出初步的领域和限界上下文以及上下文之间的关系
(3)进一步分析每个上下文内部识别出哪些是实体哪些是值对象
(4)对实体、值对象进行关联和聚合划分出聚合范畴和聚合根进行建模
(5)将每个业务场景流程化按照场景流程使用事件编排定义好事件上下游关系
(6)在工程中实践领域模型并在实践中检验模型的合理性倒推模型中不足的地方并重构。 参考
领域驱动架构DDD建模中的模型到底是什么 - 知乎
一文教会你领域建模-CSDN博客
DDD-领域驱动设计 - 知乎
