领域驱动设计-分享

概述

领域驱动不是纯粹的技术问题,领域建模(建立数据表只是一部分)是领域专家(客户/产品团队)和开发人员沟通努力、抽象的的结果。

领域建模的目的是,经过有效的沟通、详细分析、 良好设计可以更好的适应未来的变化。

领域驱动设计的核心是建立正确的领域模型。

面向人员

后端开发人员、产品人员

一、背景

  1. 领域驱动设计是什么?

    领域驱动设计的核心是建立正确的领域模型,正确的反应业务,并适应变化。

  2. 为什么建立一个领域模型是重要的

    (1). 领域模型是具有边界的领域抽象,反映了领域业务需求的本质,边界指只领域内所关注的部分;

    (2). 领域模型只反映业务,和任何技术实现无关, 包括实体概念(如商品)和过程概念(资金转账);

    (3).领域模型确保业务逻辑内聚在一个模型中,帮助可理解和重用;

    (4). 领域模型帮助开发人员平滑转换为软件构造;

    (5).领域模型贯穿软件分析设计开发整个过程,领域专家、设计、开发人员始终保持沟通,共享信息,确保软件真正满足需求;

    (6).建立正确的领域模型并不简单,需要领域专家、设计、开发人员积极沟通共同努力,然后才能使大家对领域(业务需求)的认识不断深入,从而不断细化和完善领域模型;

    (7).领域模型是整个软件的核心,是最有价值和最具竞争力的部分;设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化;

  3. 领域建模时思考问题的角度

二、概念

领域驱动分层

User Interface 用户界面层

在PC页面、APP界面、WebAPI接口展示数据;

发送命令给应用层要求其执行某个用户命令;

Application 应用层

定义系统要完成的所有任务,对用户界面层提供应用功能。对内调用领域层(领域对象或领域服务)完成业务逻辑,应用层不包含业务逻辑。

Domain 领域层

负责表达业务概念,业务状态信息以及业务规则,领域模型处于这一层,是业务软件的核心。

限界上下文

限界上下文是个高内聚的领域模型(例订单模块),是未来系统做水平拆分的关键,可以说就是将一个限界上下文模型拆分升级为一个子系统。

开发人员可以简单理解,限界上下文可以转换成代码,放在一个高内聚的dll项目;

AggregateRoot 聚合根

聚合,它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚,并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合,我们把聚合看作是一个修改数据的单元。

聚合的特点:

(1). 每个聚合有一个根和一个边界,边界定义了一个聚合内部有哪些实体或值对象,根是聚合内的某个实体;

(2). 聚合内部的对象之间可以相互引用,但是聚合外部如果要访问聚合内部的对象时,必须通过聚合根开始导航,绝对不能绕过聚合根直接访问聚合内的对象,也就是说聚合根是外部可以保持 对它的引用的唯一元素;

(3). 聚合内除根以外的其他实体的唯一标识都是本地标识,也就是只要在聚合内部保持唯一即可,因为它们总是从属于这个聚合的;

(4). 聚合根负责与外部其他对象打交道并维护自己内部的业务规则;

(5). 基于聚合的以上概念,我们可以推论出从数据库查询时的单元也是以聚合为一个单元,也就是说我们不能直接查询聚合内部的某个非根的对象;

(6). 聚合内部的对象可以保持对其他聚合根的引用;
删除一个聚合根时必须同时删除该聚合内的所有相关对象,因为他们都同属于一个聚合,是一个完整的概念;

如何识别聚合及聚合根?

我觉得我们可以先从业务的角度深入思考,然后慢慢分析出有哪些对象是:
有独立存在的意义,即它是不依赖于其他对象的存在它才有意义的;
可以被独立访问的,还是必须通过某个其他对象导航得到的;

如何识别聚合根?

如果一个聚合只有一个实体,那么这个实体就是聚合根;如果有多个实体,那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。

Entity 实体

不能独立存在的业务对象,必须挂在聚合根上。

ValueObject 值对象

定义:在领域中,不需要唯一键标识的对象,包括:

常见的值对象:

字符串常量;

枚举;

无主键约束的引用对象;

如果有两个Customer的地址信息是一样的,我们就会认为这两个Customer的地址是同一个。也就是说只要地址信息一样,我们就认为是同一个地址Address。

Domain Service 领域服务

领域中的一些概念不太适合建模为对象,即归类到实体对象或值对象,因为它们本质上就是一些操作,一些动作,而不是事物。这些操作或动作往往会涉及到多个领域对象。

领域服务一个很重要的功能就是可以避免领域逻辑泄露到应用层。

Domain Event 领域事件

容易降低耦合,方便做到高扩展性;

领域聚合根之间很难做到强一致性,大多数都是最终一致性;

Infrastructure 基础设施层

本层为其他层提供通用的技术能力;提供了层间的通信;为领域层实现持久化机制;总之,基础设施层可以通过架构和框架来支持其他层的技术需求;

三、案例分析

那些是聚合、聚合根、实体、值对象?

注意

开发人员/团队需要和产品团队/客户保持充分的沟通。

原文地址:https://www.cnblogs.com/supernebula/p/8449601.html

时间: 2024-10-11 13:14:27

领域驱动设计-分享的相关文章

【无私分享:ASP.NET CORE 项目实战(第三章)】EntityFramework下领域驱动设计的应用

目录索引 [无私分享:ASP.NET CORE 项目实战]目录索引 简介 在我们 [无私分享:从入门到精通ASP.NET MVC] 系列中,我们其实也是有DDD思想的,但是没有完全的去实现,因为并不是所有的好的东西都必须要用到的,还是根据实际情况,DDD在大型的系统中是非常好的一种设计思想,这点不否认.但是根据具体情况而言,在我们小型的项目中,我们设计框架的更多考虑的是让使用者快速.便捷的开发,能快速的了解框架进行项目开发. 重构我们的思路 最近研究了一下几位大神的博客,特别是:@腾飞(Jess

【华为云技术分享】如何设计高质量软件-领域驱动设计DDD(Domain-Driven Design)学习心得

DDD做为软件设计方法于2004年提出,一直不温不火,最近几年突然火起来了,为啥呢?正所谓机会给有准备的人,因为微服务的流行,大家都跃跃欲试把传统单体软件转成微服务架构,但理论很丰满,现实很骨感,光是分解微服务就让人找不到北,而DDD是歪打正着也好,富有远见也好,正好适合微服务转型设计,不火都难. 最近学习了领域驱动设计(Domain-Driven Design),感觉受益匪浅,那到底啥是DDD呢?这里分享一下学习心得.网上有很多详细的资料,感兴趣可以看看这个https://www.infoq.

分享我对领域驱动设计(DDD)的学习成果

本文内容提要: 1. 领域驱动设计之领域模型 2. 为什么建立一个领域模型是重要的 3. 领域通用语言(Ubiquitous Language) 4.将领域模型转换为代码实现的最佳实践 5. 领域建模时思考问题的角度 6.领域驱动设计的标准分层架构 7. 领域驱动设计过程中使用的模式 关联的设计 实体(Entity) 值对象(Value Object) 领域服务(Domain Service) 聚合及聚合根(Aggregate,Aggregate Root) 工厂(Factory) 仓储(Rep

我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践

写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课.第一次骑自行车.第一次懂事.第一次和喜

(转载)浅谈我对DDD领域驱动设计的理解

原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故

.NET领域驱动设计—实践(穿过迷雾走向光明)

阅读目录 开篇介绍 1.1示例介绍 (OnlineExamination在线考试系统介绍) 1.2分析.建模 (对真实业务进行分析.模型化) 1.2.1 用例分析 (提取系统的所有功能需求) 1.3系统设计.建模 (技术化业务模型) 1.3.1 枚举类型的使用 (别让枚举类型成为数值型对象) 1.3.2 基础数据.业务数据 (显示实体和隐式过程) 1.3.3 模型在数据库中的主外键关联问题 (面向对象模型与关系模型的天然抗阻) 1.3.4 角色.类型 (区分类型与面向对象概念) 1.3.5 名词

.NET领域驱动设计—看DDD是如何运用设计模式颠覆传统架构

阅读目录: 1.开篇介绍 2.简单了解缘由(本文的前期事宜) 3.DomainModel扩展性(运用设计模式设计模型变化点) 3.1.模型扩展性 3.2.设计模式的使用(苦心专研的设计模式.设计思想可以随意使用了) 3.3.部分类的使用(封装内部对象) 3.4.高强度的OO设计(面向特定领域的高度抽象设计形成特定领域框架) 4.DomainModel业务逻辑规则配置(将扩展点分离后使用适当的配置将规则IOC进去) 5.DDD简单总结(DDD是什么?它是"战术") 1]开篇介绍 这篇文章

DDD领域驱动设计仓储Repository

DDD领域驱动设计初探(二):仓储Repository(上) 前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇

EntityFramework之领域驱动设计实践

EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动设计实践 (五):聚合 EntityFramewor