上一篇:<IDDD 实现领域驱动设计-由贫血导致的失忆症> 这篇博文是对<实现领域驱动设计>第一章后半部分内容的理解. Domain Experts-领域专家 这节点内容是昨天的一个讨论引发的思考. 什么是领域专家?简单来说,就是对某一业务领域精通的人,这个人可以是医生.学者.作家.艺术家等等,不管是什么职业,什么身份,只要对某一业务领域精通,都可以称之为领域专家.这样说可能会让你感到茫然,我举一个例子,比如你们软件公司要开发一套快递行业的业务系统,然后你需要到实际企业去了解业务流…

上一篇:<IDDD 实现领域驱动设计-一个简单业务用例的回顾和理解> 在<实现领域驱动设计>第二章的前半部分内容中,提到领域和子域的概念,并且作者把这两者又进行了细致的区分,其实在<领域驱动设计>书中,也有进行详细说明,只不过是在第十五章<精炼>中,章节比较靠后,我先是读了<实现领域驱动设计>这部分的内容,但读完之后,完全没有任何的感觉,或者说我自己和作者没有产生一些共鸣,也记不起来自己到底读了什么内容,但是在读<领域驱动设计>对应这…

上一篇:<IDDD 实现领域驱动设计-上下文映射图及其相关概念> 在<实现领域驱动设计>书中,分层的概念作者讲述的很少,也就几页的内容,但对于我来说,有很多的感触需要诉说.之前的短消息项目使用的就是经典分层架构,但那时候是:瞎子过桥,啥也不会,现在再回过头看,满眼惆怅,还请我娓娓道来- 1. 层的含义 在第一张图中,用户界面层(User Layer)是我自作主张加上的,应用层的直接用户就是用户界面层,这里的用户界面层,也可以称之为表现层(Presentation Layer),上面…

上一篇:<IDDD 实现领域驱动设计-CQRS(命令查询职责分离)和 EDA(事件驱动架构)> 学习架构知识,需要有一些功底和经验,要不然你会和我一样吃力,CQRS.EDA.ES.Saga 等等,这些是实践 DDD 所必不可少的架构,所以,如果你不懂这些,是很难看懂上篇所提到的 CQRS Journey 和 ENode 项目,那怎么办呢?我们可以从简单的 Demo 一点一滴开始. 代码地址:https://github.com/yuezhongxin/CQRS.Sample 说明:一张很丑陋的…

上一篇:<IDDD 实现领域驱动设计-理解领域和子域> <实现领域驱动设计>前两章内容,基本上读完了,和<领域驱动设计>不同的是,它把很多的概念都放在前面进行讲述了,比如领域精炼.界限上下文等等,在<领域驱动设计>中,是很靠后的内容,不过这样也好,可以让你从一个大局的视角去看待问题,由广到细的思路学习,我觉得也蛮好的.另外,随着一点一点的学习,你会发现,领域驱动设计越来越有意思了,有很多"新鲜"的东西等待发现. 一张很重要的图(无意间搜到…

上一篇:<IDDD 实现领域驱动设计-SOA.REST 和六边形架构> 阅读目录: CQRS-命令查询职责分离 EDA-事件驱动架构 Domin Event-领域事件 Long-Running Process(Saga)-长时处理过程 Event Sourcing-事件溯源 CQRS Journey-微软示例项目 ENode-netfocus 实践项目 存在即是理由,每一种架构的产生都会有一种特定的场景,或者解决某一种实际应用问题,经验的累积促成了某一种架构的产生. 1. CQRS-命令查询职…

上一篇:<IDDD 实现领域驱动设计-理解限界上下文> 距离上一篇有几天时间了,<实现领域驱动设计>第三章的内容都是围绕一个词-上下文映射图,我大概断断续续看了几天,总共看了两遍,但模模糊糊也不是很理解,不像前两章有一个可以触动我的地方,但有很多概念是蛮重要的,这篇没有自己的理解,大部分都是整理上下文映射图及其相关概念. 可以看作是示例上下文,大家在画上下文映射图的时候可以参照一下,后面的大部分概念,也都围绕它展开. 上下文映射图(Context Map):可以进行拆分理解,上下文…

上一篇:<IDDD 实现领域驱动设计-架构之经典分层> 阅读目录: SOA-面向服务架构 REST 与 RESTful 资源(Resources) 状态(State) 六边形架构 DDD 的一大好处就是并不需要使用特定的架构,经典分层架构只是一种,由于核心域位于限界上下文中,我们可以使用多种风格的架构,既然如此,我们应该把眼界看的更宽广些,有意思的东西多着呢. SOA 和 REST 这两个货,我们都比较熟悉,他俩并不是由 DDD 引入,但却可以适用于 DDD.我个人觉得,要想把他俩发挥好,最好…

啰嗦几句 年前的时候,在和 netfocus 兄,以及对 DDD 感兴趣园友的探讨过程中,我发现自己有很多不足的地方,对 DDD 的了解也只是皮毛而已,代码写的少,DDD 的基本概念也不是很清楚,空有一腔热爱之情是做不了事的,后来我就多写技术代码,也记录了很多的技术问题,这让我收获很多,.NET 开源等等一系列的事件,也让我们 .NET 技术阵营看到了一丝希望. 后来,在探讨的过程中,有很多我不知道的概念被讨论,比如 CQRS.六边形架构.事件溯源等等,我对这些概念是一窍不通的,像六边形架构,我…

最近新接了一个业务系统——社区服务系统,为了快速熟悉和梳理老系统的业务逻辑和代码,同时对老系统代码做一些优化,于是打算花上一个月时间不间断地对老系统服务进行重构.同时,考虑到社区业务的复杂性,想起了之前做用户系统时尝试过的领域驱动建模(简称DDD,英文全称为:Domain Driven Design),思量之下,觉得DDD非常适合这种复杂业务逻辑的系统.毫不迟疑,开搞! 之前在做用户系统时,也尝试使用DDD进行业务建模,但迫于项目工期压力,没有进行深入的学习和建模,最后效果不是很理想,为了避免重…

领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家…

领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家…

写在前面 阅读目录: 具体业务场景 业务需求变化 "愚蠢"的应对 消息列表实现 消息详情页实现 消息发送.回复.销毁等实现 回到原点的一些思考 业务需求变化,领域模型变化了吗? 对象读取的额外思考 写在最后 领域驱动设计的核心-Domain Model(领域模型),这个大家都知道,可是,上次关于领域模型的设计分享,要追溯到两个月之前了,这中间搞了一些有的没有的东西,比如纠结于仓储等,说这些东西不重要,其实也蛮重要的,因为它是一个完整应用程序所必须要考虑的东西(Demo 除外),但是相对…

本文是基于上一篇‘业务建模小招数’的实践,后面的多篇博文类似.本文主要讲解‘发表帖子’场景的业务建模,包括:业务建模.业务模型.示例代码:示例代码会使用java编写,文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的第一篇,可参考:通过业务系统的重构实践DDD 业务建模 —— Round-I 业务建模 在大家的常识中,每个人都有自己的观点,并可以发表自己的观点,在社区中便表现为:发布帖子.那么谁…

本文结合团队在COMMUNITY(社区服务系统)业务建模过程中的实践经验,总结得到一些DDD业务建模的小招数,不一定是完美的,但是对我们团队来说很有效用,希望能帮到其他人.后面会陆续将项目中业务建模的一些经典例子放上来,分享给大家. COMMUNITY系统是线上旧系统,它的建模过程有别于新系统的业务建模.由于背着历史包袱,COMMUNITY的建模过程不是那么纯粹,很容易受到旧代码的影响,陷入代码的细节中,初期举步维艰,靠着小步快跑的方式得到了一些雏形和方法论,后面越来越顺,效果还是不错的. 本文…

最近在做电商业务中,有关商品业务改版的一些东西,后端的架构设计采用现在很流行的微服务,有关微服务的简单概念: 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力. 关于改版的业务设计,还是想尝试 DDD 领域驱动设计,之前写的一些相关文章,都是直接进行战术设计,而非在战略设计基础上进行,所以最后可能会出现一些问题,所以这次的过程是…

前言 领域驱动设计,其实已经是一个很古老的概念了,但它的复杂度依旧让学习的人头疼不已. 互联网关于领域驱动的文章有很多,每一篇写的都很好,理解领域驱动设计的人都看的懂. 不过,这些文章对于那些初学者而言,还是如同天书一样. 买本驱动领域的书来看?别逗了,这可不是C#语法入门,哪里有书能写明白的. 想学会领域驱动设计,只有一途——实践,不断的实践. 领域驱动设计是什么? 领域驱动设计就是我们俗称的DDD,英文全拼是Domain-Driven Design. 我认为,理解领域驱动设计的第一步是,顾名…

.net core +codefirst(.net core 基础入门,适合这方面的小白阅读)   前言 .net core mvc和 .net mvc开发很相似,比如 视图-模型-控制器结构.所以.net mvc开发员很容易入手.net core mvc .但是两个又有细微的区别,比如配置.net mvc中Web.config和Global.asax消失,而在.net core mvc中则是Startup.cs.Program.cs.appsettings.json等等.所以想要深入了解.ne…

我们使用领域驱动设计(英文缩写为DDD)的方法来设计引擎,在引擎开发的过程中,领域模型会不断地演化. 本文介绍本系列使用的领域驱动设计思想的相关概念和知识点,给出了相关的资料. 上一篇博文 从0开发3D引擎(七):学习Reason语言 下一篇博文 从0开发3D引擎(八):准备"搭建引擎雏形" 概览 下面的资料粗略地介绍了DDD的相关知识点: 领域驱动设计学习输出 领域驱动设计(DDD)部分核心概念的个人理解 系统学习资料 相关资料为: DDD理论学习系列 为什么用DDD 参考领域驱动设…

目录 系列文章 领域逻辑和应用逻辑 多应用层 示例:正确区分应用逻辑和领域逻辑 学习帮助 系列文章 基于ABP落地领域驱动设计-00.目录和前言 基于ABP落地领域驱动设计-01.全景图 基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践和原则 基于ABP落地领域驱动设计-03.仓储和规约最佳实践和原则 基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则 基于ABP落地领域驱动设计-05.实体创建和更新最佳实践 基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑…

前面几篇blog主要介绍了DDD落地架构及业务建模战术,后续几篇blog会在此基础上,讲解具体的架构实现,通过完整代码demo的形式,更好地将DDD的落地方案呈现出来.本文是架构实现讲解的第一篇,主要介绍了DDD的User Interface层的实现,详细讲解了controller.dto的职责和实现,已经UI层使用到的公共组件:CheckLogin.Loging.Validation的职责和实现细节.文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景…

本文是DDD框架实现讲解的第二篇,主要介绍了DDD的Application层的实现,详细讲解了service.assemble的职责和实现.文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的其中一篇,其他可参考:使用领域驱动设计思想实现业务系统 Application层 在DDD设计思想中,Application层主要职责为组装domain层各个组件及基础设施层的公共组件,完成具体的业务服务.A…

本文是DDD框架实现讲解的第三篇,主要介绍了DDD的Domain层的实现,详细讲解了entity.value object.domain event.domain service的职责,以及如何识别出领域中的这些对象,并附有具体的业务建模示例.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的其中一篇,其他可参考:使用领域驱动设计思想实现业务系统. Domain层 Domain层是具体的业务领域层,是发生业务变化最为频繁…

在社区系统的DDD实践过程中,将遇到一些问题和产生的想法记录下来,共讨论. 本文为[DDD]系列文章中的其中一篇,其他内容可参考:使用领域驱动设计思想实现业务系统. 1.dto.model和entity之间的互相转化 user interface层的dto.domian层的model.infrastructure层的entity之间的互相转换,比较繁琐,硬编码容易出错. 如果命名较为规范,则可以考虑交给一个公共服务完成自动转换,约定俗成:dto和model为驼峰式命名,entity和数据库表保持…

写在前面 上一篇:DDD 领域驱动设计-看我如何应对业务需求变化,愚蠢的应对? "愚蠢的应对",这个标题是我后来补充上的,博文中除了描述需求变化.愚蠢应对和一些思考,确实没有实质性的应对,文不对题,实在惭愧. 这次应对,我们从领域模型开始. 领域模型思考 业务需求变化,关于领域模型的调整,上一篇我只给出了一些思考,但这段内容,我觉得是那篇博文最重要的地方,不知道你仔细看了没,我一直在强调"回复的概念",以及之前领域模型没有"回复"所造成的一些问题…

阅读目录: 1.背景介绍 2.在业务层中加入核心领域模型(引入DomainModel,让逻辑.数据有家可归,变成一个完整的业务对象) 3.统一协调层Application Layer(加入协调层来转换DomianModel) 4.从数据扁平结构转换成OO体系结构(使用OO丰富代码结构) 5.DomainModel中的内容(带开关的Specification.SOA化的Specification) 6.模式.重构.单元测试在领域模型中的运用 1.背景介绍 由于时间关系废话不多扯了,直奔主题,对领域…

本文结合团队在ECO(社区服务系统)业务建模过程中的实践经验,总结得到一些DDD业务建模的小招数,不一定是完美的,但是对我们团队来说很有效用,希望能帮到其他人.后面会陆续将项目中业务建模的一些经典例子放上来,分享给大家. ECO系统是线上旧系统,它的建模过程有别于新系统的业务建模.由于背着历史包袱,ECO的建模过程不是那么纯粹,很容易受到旧代码的影响,陷入代码的细节中,初期举步维艰,靠着小步快跑的方式得到了一些雏形和方法论,后面越来越顺,效果还是不错的. 本文为[DDD]系列文章中的其中一篇,其…

DMVP,全称DDD-MVP,是基于领域驱动设计(DDD)搭建的业务框架,整体设计符合DDD领域模型的规范,业务上达成了领域模型和代码的一一映射,技术上达成了高内聚低耦合的架构设计,开发人员不需要关注DDD框架设计,只需专心写业务逻辑即可,节约了人力成本. DMVP框架特点: 1:通过页面简单配置,即可生成规范的DDD战术框架,只需在框架内实现业务逻辑即可. 2:代码和领域模型的统一对应,制定了领域模型和代码的对应规范,做到代码即领域模型,即业务. 3:框架由多年实战经验总结而成,实战过大型互联…

上一篇:<DDD 领域驱动设计-如何 DDD?> 开源地址:https://github.com/yuezhongxin/CNBlogs.Apply.Sample(代码已更新) 阅读目录: JsPermissionApply 生命周期 改进 JsPermissionApply 实体 重命名 UserAuthenticationService 改进 JsPermissionApplyRepository 改进领域单元测试 如何完善领域模型?指的是完善 JS 权限申请领域模型,也就是 JsPerm…

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