接触领域驱动设计DDD有一年多的时间了,中间看过不少书,参与过一些讨论(ENode QQ群).目前对DDD的认知还停留在理论阶段,所以对领域建模非常感兴趣,这里说的建模是指以DDD的思想为指导再加上DDD的工具,比如聚合.实体.值对象等等. 昨天有群友分享了一个建模的案例,我想在这儿记录下来,有两个目的:1.为自己学习DDD储存素材  2.锻炼自己写文章的能力 关于DDD中的一些概念,请见如下文章链接: http://www.cnblogs.com/ivanzheng/p/5533162.htm

整理一个精简的DDD领域建模基本流程,供大家在DDD领域建模实践中进行参考. 搜集用户故事(用户的原始需求) 整理用户故事,抽出用例(用例表达了用户对系统的需求,定义了系统的边界以及系统外部角色和系统的交互场景) 分析系统需求,将领域拆分为多个子域(领域是问题空间,本质上就是大问题拆分为小问题) 抽取每个子域的领域概念,得到概念模型(概念模型存在于问题空间) 将子域的概念模型抽象并转化为领域模型(领域模型存在于解决方案空间,这一步是难点,考验抽象能力,如对关系的建模,如促销系统中抽象出促销产品,

以DDD为开发模式的设计开发步骤可以是:1)分析需求:2)画出用例图,系统中各个角色如何使用系统,也包括外部系统如何使用系统,也包括系统中到某个时间点自动启动的某些功能(此时角色就是时间):3)针对各个用例图,就知道了系统使用的各种业务场景,同时也明确了系统的边界,从而就明确了领域模型的边界:4)在领域模型的边界内划分聚合,找出每个聚合的边界,找出边界内的聚合根,实体,值对象:这步是难点.这里一定不能混淆的一个概念是,领域建模不是以用户为中心的建模,而是以用户的需求为中心的建模.所以要努力寻找各

UML:聚合关系:成员对象是整体的一部分,但是成员对象可以脱离整体对象独立存在.如汽车(Car)与引擎(Engine).轮胎(Wheel).车灯(Light)之间的关系为聚合关系,引擎.轮胎.车灯可以脱离车而存在,比如把一个引擎换到另一个汽车上也可以. 组合关系:也表示的是一种整体和部分的关系,但是在组合关系中整体对象可以控制成员对象的生命周期,一旦整体对象不存在,成员对象也不存在,整体对象和成员对象之间具有同生共死的关系. 所以,聚合和组合的差别就一点:整体和部分的生命周期是否一致,即整体消亡

最近发现文章老是被窃取,有些平台举报了还没有用.请识别我的id方丈的寺院. 摘要 DDD领域驱动设计,起源于2004年著名建模专家Eric Evans发表的他最具影响力的著名书籍:Domain-Driven Design –Tackling Complexity in the Heart of Software(中文译名:领域驱动设计,之后进行了很多迭代和演化,不过大多没有脱离这本书讨论的范围.因为Eric Evans在该书中只是提供了一套原始理论,并没有提供一套方法论,更别说可落地.所以十几年

前言 本文想再讨论一下关于领域.业务.业务模型.解决方案.BC.领域模型.微服务这些概念的含义和关系.初衷是我发现现在DDD领域建模以及解决方案落地过程中,常常对这些概念理解不清楚或者有歧义,导致我们不知道如何运用这些概念来落地我们的软件.先通过一个图来说明一下这些概念之间的关系,如下图所示 领域.业务.业务模型 领域,即问题域.问题空间,领域是一种边界.范围.所以,一个领域代表了一个问题域的边界,也可以理解为是一个业务的边界.领域边界越大,业务范围就越大,反之则相反:通常我们大家交流都比较喜欢

上图是一张普通地图,最刺眼的就是边界? 非常好奇地图绘制工程师是如何描绘如此弯曲多变的边界的?强制行政区域还是人群历史原因自然的人以群分? 我们再换个视角,对工程师或者架构师来说,微服务的边界如何划分呢? 基于DDD设计方法论中的概念 限界上下文 来划分微服务的边界: 背景 架构师小李正在团队推行DDD设计方法论,领域建模和系统建设过程中,很多岗位需要参加进来,比如产品经理,领域专家,项目经理,架构师,开发经理,测试经理.对同样的领域知识,不同的人可能有不同的认识,交流起来存在一定障碍. 假如你

目录 学好了DDD,你能做什么? 领域驱动设计:微服务设计为什么要选择DDD? 领域.子域.核心域.通用域和支撑域:傻傻分不清? 限界上下文:定义领域边界的利器 实体和值对象:从领域模型的基础单元看系统设计 聚合和聚合根:怎样设计聚合? 领域事件:解耦微服务的关键 DDD分层架构:有效降低层与层之间的依赖 微服务架构模型:几种常见模型的对比和分析 中台:数字转型后到底应该共享什么? DDD.中台和微服务:它们是如何协作的? 学好了DDD,你能做什么? 我认为,要想应用 DDD,首要任务就是要吃透

聚合与聚合根的含义 聚合: 聚合往往是一些实体为了某项业务而聚类在一起形成的集合 , 举个例子, 社会是由一个个的个体组成的,象征着我们每一个人.随着社会的发展,慢慢出现了社团.机构.部门等组织,我们开始从个人变成了组织的一员,大家可以协同一致的工作,朝着一个最大的目标前进,发挥出更大的力量.领域模型内的实体和值对象就好比个体,而能让实体和值对象协同工作的组织就是聚合,它用来确保这些领域对象在实现共同的业务逻辑时,能保证数据的一致性.可以这么理解,聚合就是由业务和逻辑紧密关联的实体和值对象组合而

本次分享价值:本次分享主要针对中台.微服务和领域模型的理念.本质及其构建方法论进行探讨.对领域分析的价值所在就是寻求"千变万化"中相对的"稳定性.第一性",然后通过合理的架构分析及抽象隔离业务的复杂度和技术复杂度,隔离业务领域的稳定性和易变性,从架构上精巧.快速的支撑业务的变化. 中台到底是什么? 中台的概念最早是从阿里流传出来的,阿里的中台战略是从业务中台和数据中台开始的,采用业务中台和数据中台相结合的双中台建设模式.后来也有人提出技术中台,AI中台等等. 在阿里

大家好,我叫汤雪华.我平时工作使用Java,业余时间喜欢用C#做点开源项目,如ENode, EQueue.我个人对DDD领域驱动设计.CQRS架构.事件溯源(Event Sourcing,简称ES).事件驱动架构(EDA)这些领域比较感兴趣.我希望把自己所学的知识能否分享给大家,所以,把这个领域里的一些知识串联了起来,整理了一个PPT,并为每张PPT配备注释,分享给大家.希望能对这个领域有兴趣的朋友有所帮助. 上面的提纲是今天主要分享的内容概要.开始之前想先说一下微服务架构和CQRS架构的区别和

选择ENode意味着什么可能很多人还不太清楚.我简单整理了一下: 意味着你选择了:你需要做DDD领域建模.选择了事件驱动的架构.选择了CQRS架构.选择了最终一致性.选择了事件溯源.选择了分布式.这些你都调研过了,再考虑是否你需要使用. 所以ENode不是一个简单的类库型的框架,它是一个架构型的框架.选择了ENode,意味着你已经做了架构选型,因为ENode定义好了架构,你用ENode写代码,只需要在合适的地方填合适的代码即可.ENode不像log4net,autofac,dapper这种,只是

MVC模式:Model模型 View试图 Control控制器,是目前主流模式,被当作服务器软件入门基本模式学习和掌握,主流框架Struts 1/2 JSF Wicket基本都顺理成章支持MVC模式. 但是,随着时间推移,MVC模式也暴露出大量缺点,因为MVC模式本质上是一个结构型模式,结构模式相比行为模式而言,实际就是静止的,相对固定的,而随着B/S和互联网应用不断普及,Web 2.0和社会化媒体 以及游戏等大量频繁交互应用普及,相对静止的MVC模式已经不适合高度交互注重行为的应用了. DDD

阅读目录 前言 场景1的思考 场景2的思考 避坑方式 实践 结语 一.前言 在上一篇中(如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成),有一行注释的代码: public interface IRoleDiscountRelationRepository// : IRepository<RoleDiscountRelation> { RoleDiscountRelation Get(string roleId); } 其中涉及的到问题是关于值对象的持久化问题.是的,由于我们之前的

一.前言 结合我们本次系列的第一篇博文中提到的上下文映射图(传送门:如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念),得知我们这个电商网站的核心域就是销售子域.因为电子商务是以信息网络技术为手段,以商品交换为中心的商务活动,一个好的核心域设计可以大大提升企业的竞争力和对市场变化的相应速度. 那么我们开始设计领域对象.对于设计领域对象的基本概念不了解的可以先阅读我的该系列第二篇文章(传送门:如何一步一步用DDD设计一个电商网站(二)—— 项目架构). 二.定义几个基类 我相信我们大

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

ABP相关岗位招聘:给热爱.NET新技术和ABP框架的朋友带来一个高薪的工作机会 ABP交流会录像视频:ABP架构设计交流群-7月18日上海线下交流会的内容分享(有高清录像视频的链接) 代码自动生成:分享一个与ABP配套使用的代码生成器源码 ABP系列文章总目录: 1.ABP总体介绍  2.ASP.NET Boilerplate入门 3.ABP分层架构 4.ABP模块系统 5.ABP启动配置 6.ABP依赖注入 7.ABP Session管理8.ABP日志管理9.ABP设置管理10.ABP领域层

ENode是什么 ENode是一个.NET平台开源的应用开发框架,为开发人员提供了一套完整的基于DDD+CQRS+ES+(in-memory)+EDA架构风格的解决方案. ENode的特色是什么 解决CQRS架构的C端的高并发写的问题,以及CQ两端数据同步的顺序性保证和幂等性问题: 将并发写降低到最低,从而做到最大程度的并行.最大的吞吐量: 通过基于分布式消息队列横向扩展的方式实现系统的可伸缩性: 聚合根常驻内存,可以完全以OO的方式来设计实现聚合根,不必为ORM的阻抗失衡而烦恼: 基于EDA的

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型:

返回<8天掌握EF的Code First开发>总目录 本篇目录 理解Code First及其约定和配置 创建数据表结构 管理实体关系 三种继承模式 本章小结 自我测试 本篇的源码下载:点击下载 先附上codeplex上EF的源码:entityframework.codeplex.com,此外,本人的实验环境是VS 2013 Update 5,windows 10,MSSQL Server 2008. 上一篇<第一个Code First应用>简单介绍了如何使用EF的Code Firs