7 领域驱动设计 不明显概念建模

最新推荐文章于 2022-09-16 13:16:51 发布
最新推荐文章于 2022-09-16 13:16:51 发布
阅读量194 收藏
点赞数
分类专栏： 领域驱动设计
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dabusidede/article/details/107933735
版权

约束是非常重要的概念，模型中应该表现出来
在这里插入图片描述
业务规则不适合作为Entity或ValueObject的职责，下面介绍一种模式

模式：Specification（规格）

1.验证
在这里插入图片描述
规格类用于测试当前对象是否满足规则，注意依赖关系，是规格依赖于实体

2.查询
在这里插入图片描述
规格类用于筛选

dabusidede
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
DDD领域驱动设计二、基础概念
w1lgy的博客
11-23 943
文章目录一、领域和子域 领域、子域、核心域、通用域、支撑域、通用语言、限界上下文、聚合、聚合根、实体、值对象、领域事件、事件风暴等等，非常多。这些名词，都是关键概念，它们非常抽象难以理解，但却又很重要，是理解 DDD 的核心设计思想和理念的基础。 一、领域和子域 ...
领域驱动设计--领域驱动设计到数据建模实践(十)
一个天秤座的架构师
10-19 2万+
----- 学习笔记 ----- 过去，系统的软件设计是以数据库设计为核心，当需求确定下来以后，团队首先开始进行数据库设计。因为数据库是各个模块唯一的接口，当整个团队将数据库设计确定下来以后，就可以按照模块各自独立地进行开发了。在上面的过程中，为了提高团队开发速度，尽量让各个模块不要交互，从而达到各自独立开发的效果。但是，随着系统规模越来越大，业务逻辑越来越复杂，我们越来越难于保证各个模块独立不交互了。 在进入DDD的数据库设计落地之前，先了解DDD基于微服务的基本设计理念： DDD基
DDD（领域驱动设计）
热门推荐
东境物语
07-08 26万+
基本概念： 　　领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名：领域驱动设计—软件核心复杂性应对之道)一书。，书中提出了“领域驱动设计(简称 ddd)”的概念。 领域驱动设...
DDD领域驱动设计详解
靖节先生的博客
06-04 5万+
DDD领域驱动设计1. 领域驱动设计1.1 什么是领域驱动设计1.2 为什么用领域驱动设计2. DDD核心知识体系2.1 DDD核心概念2.2 DDD战略战术设计2.2.1 DDD战略设计2.2.1 DDD战术设计3. DDD微服务架构模型3.1 基本架构3.1.1 DDD分层架构3.1.1 六边形理论3.1.1 CQRS架构设计3.2 代码结构3.3 服务调用 1. 领域驱动设计 1.1 什么是领域驱动设计 领域驱动设计(Domain Driven Design) 是一种从系统分析到软件建模的一套方法论
领域驱动设计（DDD）知识点整理
玖涯博客
08-12 1195
摘要 Eric Evans的“Domain-Driven Design领域驱动设计”简称 DDD，DDD 是一套综合软件系统分析和设计的面向对象建模方法，相比于面向对象设计（OO），DDD 是一种更加注重业务边界的设计方法，OO 更加注重抽象，从差异中寻找共同点，然后进行抽象，这是两种不同的思维方式。可以简单的理解为 DDD 是一种业务+解耦的设计实现，DDD 的业务边界思维能够很好的支持微服务拆分，与近些年提出的微服务理论不谋而合 。本文将描述领域驱动设计（DDD）的基础知识，以及 DDD 项目的基础项目
领域驱动设计
最新发布
weixin_44390164的博客
09-16 1651
限界上下文定义了领域的边界在同一界限上下文中，我们可以使用统一的语言进行交互。用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等有一个确切的含义，没有二义性。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案一个限界上下文理论上就可以设计为一个微服务。领域模型由领域对象组成。领域对象包括以下几种实体值对象聚合领域事件领域服务领域对象都是为了解决业务问题而创建的，它们应当包含足够的业务逻辑，而不仅仅是数据的容器。
DDD(领域驱动设计)
wuzhengfei1112的博客
01-26 4万+
Domain Driven Design(领域驱动设计, DDD)，不是一种架构，而是一种架构方法论，是一种拆解业务、划分业务、确定业务边界的方法，是一种领域设计思想。 - 核心思想：建立领域模型，领域模型处于架构的核心位置。 - 核心目标：避免业务逻辑的复杂度与技术实现的复杂度混淆在一起。 DDD包括战术设计和战略设计两部分。 - 战略设计：侧重于高层次、宏观上去划分和集成限界上下文。 - 战术设计：关注更具体使用建模工具来细化上下文。
知识树沉淀总结-领域驱动设计DDD
小人物的草稿本
06-12 1015
DDD改变了传统软件开发工程师针对数据库进行的建模方法，将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。...
DDD领域驱动设计基本理论知识总结
纸上得来终觉浅，绝知此事要躬行
03-09 1338
领域驱动设计之领域模型 加一个导航，关于如何设计聚合的详细思考，见这篇文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。领域驱动设计分为两个阶段： 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型； 由领域模型驱动软件设计，用代码来实现该领域模型；
《领域驱动设计 DDD》核心知识梳理笔记
舒哥的blog
10-30 2207
本书是毕业后读的第二本偏专业书，刚工作读的第一本教的是代码层面的如何让具体实现更优雅， 而这本书旨在提升抽象能力、顶层设计、领域建模能力。看书的过程中，书里解答了之前工作中很多的困惑，比如 团队间，项目模块间如何界定边界？有没有好的方式让项目代码摆脱越来越不可控的结局？另外更重要的是，我们看书的过程中，对内容的思考不要局限在工作本身， 里面的思想完全可以指导对生活中的领域问题如何建模，体会生活的别致与美妙。书里很多共鸣也有很多内容由于工作经验不足体会不深，目前对这座丰碑的精华摄取尚浅，期待在后续的工作和生活
领域驱动设计第二分卷
08-14
9.2 如何建模不太明显的概念 164.. 9.2.1 显式的约束 165 9.2.2 作为领域对象的流程 167 9.2.3 规格 168 9.2.4 规格的应用和实现 171 第10章 柔性设计 184 10.1 释意接口 186 10.2 无副作用函数 190 10.3 ...
领域驱动设计第一分卷
08-14
9.2 如何建模不太明显的概念 164.. 9.2.1 显式的约束 165 9.2.2 作为领域对象的流程 167 9.2.3 规格 168 9.2.4 规格的应用和实现 171 第10章 柔性设计 184 10.1 释意接口 186 10.2 无副作用函数 190 10.3 ...
3 CQRS Saga 模式
dabusidede的博客
08-17 3695
概念 总线：负责发送命令、事件、持久化Saga 命令：描述一个命令 事件：描述一个事件 处理器：处理命令或事件 Saga：代表一个流程，是由完成一个流程的一系列处理器组成 什么是Saga Saga代表一个流程 如下订单流程 下订单包含如下命令和事件： 下订单命令： 用于开启saga流程，此时saga被创建并持久化（如保存到数据库中），用户点击“下单”时，发送一个Http请求触发该命令，该命令会发送“检查商品库存命令” 检查商品库存命令： 这里会检查商品库存，如果库存充足，则创建“订单聚合”，状态为未支付，并
业务逻辑去处 —— 聚合，Manager，领域服务，应用服务
dabusidede的博客
09-19 1223
一段业务逻辑到底应该放在那，以下是我个人的以下判断，如果意见不同，可以评论指出哈 聚合，Manager，领域服务是领域层常见的3个对象，一段领域逻辑应该放在聚合，Manager还是领域服务中还是应用服务中？如下判断 注：这里所说的Manager是UserManager，RoleManager，PermissManager等相对于单个聚合的对象，可以把他当作一个仓库处理 放在应用服务还是领域层？ 需要对多个聚合进行操作 1.如果逻辑的步骤是可分开的，那么放在应用层，如下实例 逻辑：修改手机号，修改备注 用户可
接口与 Dto 设计
dabusidede的博客
08-12 1198
以下为个人观点，给出了基本增删改查接口的设计，如有不同观点，可以指正： Dto与查询接口设计 Dto设计：为每个实体建立一个对应的Dto 列表查询：返回聚合根的Dto列表或自定义的Dto 单个实体查询：返回整个聚合的Dto或自定义的Dto 命令接口设计 以下是基本的命令接口（增删改），根据业务逻辑是否允许如下操作进行添加 增加：增加一个聚合根 修改：前端发送整个聚合，后端修改整个聚合 删除：删除整个聚合 这样设计的原因是为了减少接口的数量，前提是聚合允许这样操作，但并不是每个聚合都允许这样操作，例如用户聚合
5 领域驱动设计 仓库
dabusidede的博客
08-11 1073
仓库用于持久化实体（你可以持久化到本地硬盘，或数据库等），在查询时恢复实体 只有聚合根才有仓库，聚合根内部通过聚合索引访问 通过仓库对聚合进行增删改查 仓库不会提交事物，事物提交在应用层 如下一个示例： // 页面仓库 // PageBase 聚合根 // EfRepository 基类包含了对实体的 增删改查 等操作 public class PageRepository : EfRepository<PageBase, int>, IPageRepository { public P
领域，上下文，子域关系图
dabusidede的博客
08-12 905
9 领域驱动设计 边界上下文
dabusidede的博客
08-11 565
边界上下文是一个领域概念，其声明了当前模型的应用范围 如： 前台客房预订系统（位于客房预订上下文中）与后台客房管理系统（位于客房管理上下文中）不在一个边界上下文内，因为他们的模型不能共享（如：前台客房预订有订单的概念，但后台客房管理并不需要订单的概念），当我们新增一个概念“清洁员”，那么这个概念应该放在哪？明显应该放在后台客房管理系统 不同的边界上下文不应该共享代码，除非分离出共享核心 如（还是使用上面的示例）： 我们现在想要vip预订系统，vip预订系统需要使用前台客房预订系统的模型，所以vip预订系统属
领域驱动设计：复杂系统的建模利器
领域驱动设计（DDD）是软件开发中的一种策略，由Eric Evans在其著作中提出，旨在处理复杂系统的建模和分析。DDD的核心思想是将业务逻辑作为软件开发的中心，强调理解并表达业务领域的概念和规则。传统的建模方法往往...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值