ddd

目录 (?) [+] 基础定义 用于引发和调度事件的延迟方法 AddDomainEvent 聚合根 Goods.cs Organization.cs CQRS 1. 创建命令 2. 创建处理 3. 使用 IoC 的域事件调度程序 事件列表 资料： 要求：修改good表，添加 organization 基础定义 用于引发和调度事件的延迟方法 AddDomainEvent Domain\SeedWork\Entity.cs public abstract class Entity<T> { int? _requestedHashCode; T _Id; public virtual T Id { get { return _Id; } protected set { _Id = value; } } private List<INotification> _domainEvents; public IReadOnlyCollection<INotification> DomainEvents => _domainEvents?.AsReadOnly(); public void AddDomainEvent(INotification eventItem) { _domainEvents = _domainEvents ?? new List<INotification>();

DDD学习大纲 领域建模的必要性 领域建模：需求-设计的沟通、转换桥梁 DDD的战略设计 领域建模语言--描述业务需求 边界上下文Bounded-Context--微服务设计 场景驱动-6W模型 Who,Why,What,Where,When,hoW 上下文交互Context-Map 事件驱动 消息驱动 DDD的架构设计 分层架构模式 clean architecture 六边形架构 DDD的战术设计 领域模型 四色建模法 Entity 、ValueObject Domain Service Domain Event Aggregation Repository设计 api设计 DDD的专题讨论 贫血模型 充血模型 DCI : Data, Context 和 Interaction DDD参考资料 DDD学习大纲 大纲内容参考 2019-DDD实践课程 领域建模的必要性 领域建模：需求-设计的沟通、转换桥梁 1、问题域 2、核心领域 3、子领域 DDD的战略设计 领域建模语言--描述业务需求 边界上下文Bounded-Context--微服务设计 场景驱动-6W模型 Who,Why,What,Where,When,hoW 上下文交互Context-Map 事件驱动 消息驱动 DDD的架构设计 分层架构模式 clean architecture 六边形架构 DDD的战术设计 领域模型

1、引言 之前学习了解了DDD中实体这一概念，那么接下来需要了解的就是值对象、唯一标识。值对象，值就是数字1、2、3，字符串“1”，“2”，“3”，值时对象的特征，对象是一个事物的具体描述，唯一标识也是字面意思，可以代表对象的唯一特征。 2、值对象 假设你手上有一沓钞票，我们去超市购物的时候，很显然我们会根据面额去付款，不会拿20元当50元花，也不会把美元当人民币花，毕竟￥50≠$50。那对于钞票来说，我们通过钞票上印刷的数字面额和货币单位识别它。每张钞票上都印有编号，我们为什么不用这个编号来识别它呢。因为我们平时购物付款，不会用编号识别面额，编号显然是银行关心的事，与我们无关。 所以我们可以知道，对于某一特定的事物，我们可以通过值来确定它，识别它。 // 地址 public class Address { // 省份 public string province； // 城市 public string city； get()... set()... } 我们通常的写法都是这样，ID作为主键映射到数据库，以此来标识这条信息。但是一个人可以有多个地址，可以是在外租的房子，也可以是租了好多房子，也可以是自己家等等，总之一个人可以拥有很多个地址。 但是地址是不会变的，为什么这么说，例如：广东省深圳市龙岗区xx街道xx号，主人会换，但是地址是不变的。 比如现在有多个合租的人同时添加地址

最近在使用Delphi开发一种应用系统的集成开发环境。其中需要实现一个字符串拆分功能，方法基本原型应该是： procedure SplitString(src: string ; ch: Char; var stringList: TStringList); 目的是使用字符ch拆分src字符串，把拆分的结果放入stringList中。例如：src:='abc|def|ghi'; ch='|'的时候，返回的stringList应该是{abc, def, ghi}。 开始的时候，我是使用获取ch在src中出现的位置，然后使用StrUtils单元提供的RightStr方法来分割字符串，并将结果保存在stringList中的。程序如下： procedure SplitString(src: string ; ch: Char; var stringList: TStringList); var p: Integer; s: string ; begin try stringList.Clear; s := src; repeat p := Pos(ch, s); if p = 0 then begin stringList.Add(s); Break; end ; stringList.Add(LeftStr(s, p - 1)); s := RightStr(s, Length(s) -

1，引言 软件开发者大多趋向于将关注点放在数据上，而不是领域上。这对于刚入门的DDD的新手而言也是如此。以我目前的思考方式，数据库依然占据主要的地位。开发一个功能，首先我就会考虑我会用到哪些属性，这些属性又有什么外键关系，而不是直接在脑海中产生一个领域的概念，这样会将数据直接反应在对象上，这会产生大量的get和set方法，虽然现在有工具可以生成get和set，但这确不是DDD的做法。 2.实体(Entity) 实体本质、具体事物、个别主体、现象的支持者等意义,其含义一般是指能够独立存在的、作为一切属性的基础和万物本原的东西。 对于java而言，实体就是属性类，通常定义在model层里面。 而DDD中要求实体是唯一的且可持续变化的。意思是说在实体的生命周期内，无论其如何变化，其仍旧是同一个实体。唯一性由唯一的身份标识来决定的。可变性也正反映了实体本身的状态和行为。 为什么要使用实体？ 当我们需要考虑一个对象的个性特征，或者需要区分不同的对象时，我们引入实体这个领域概念。 ddd的实体都做了些什么？ 传统的实体只做值得传递作用，这无疑是相对浪费资源的，DDD的思想就是在实体中存在一些业务，例如：生成订单号，判断金额不能低于0.01等业务，这样可以减轻service层的压力。 3.小结 实体是存在贫血、充血、胀血这些特征，在之前的学习中有说到过，DDD的实体就是充血实体

前言 今天是个开心的日子，又是周末，可以安心轻松的写写文章了。经过了大概3年的DDD理论积累，以及去年年初的第一个版本的 event sourcing 框架的开发以及项目实践经验，再通过今年上半年利用业余时间的设计与开发，我的enode框架终于可以和大家见面了。 自从Eric Evan提出DDD领域驱动设计以来已经过了很多年了，现在已经有很多人在学习或实践DDD。但是我发现目前能够支持DDD开发的框架还不多，至少在国内还不多。据我所知道的java和.net平台，国外比较有名的有：基于java平台的是 axon framework ，该框架很活跃，作者也很勤奋，该框架已经在一些实际商业项目中使用了，算比较成功；基于.net平台的是 ncqrs ，该框架早起比较活跃，但现在没有发展了，因为几乎没人在维护，让人很失望；国内有：banq的 jdon framework 可以支持 DDD+CQRS+EventSourcing的 开发，但是它是基于java平台的，所以对于.net平台的人，没什么实际用处；.net平台，开源的主要就是园子里的晴阳兄开发的 apworks 框架。晴阳兄在DDD方面，在国内的贡献很大，写了很多DDD系列的文章，框架和案例并行，很不错。当然，我所关注的紧紧是c#和java语言的框架，基于scala等其他语言实现的框架也有很多，这里就不一一例举了。

有一段时间没有到博客园写技术博客了，不过每天逛逛博客园中大牛的博客还是有的，学无止境…… 最近在写些调用他人接口的程序，用到了大量的JSON、XML序列化和反序列化，今天就来总结下json的序列化和反序列化的实现，有写得不好的望园中博友多多指教。 json序列化和反序列化帮助类： using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Runtime.Serialization; using System.Runtime.Serialization.Json; using System.IO; using System.Text.RegularExpressions; using System.Web.Script.Serialization; namespace HelpClass.TypeHelp { /// <summary> /// 在VS中需要添加引用System.Web.Script.Serialization的时候，请先引用System.Web.Extensions /// </summary> public class JsonHelp { /// <summary> /// json序列化（非二进制方式） /// <

　　因为不想对原文进行修改了，所以直接把评论贴上来了，现在看来，当年的认识确实有些问题，不只评论提到的，当年只是按部就班，其实真的做好应该是于无声处听惊雷，不过既然是给初学者看的，还是从简单的地方来吧，虽然有问题，但是对初学者来说也是有参考价值的，还是建议看一看想一想，尤其那些整天提DDD，但是书都没看过的 2016-05-31 12:46 ImCoOLeR 写得不错，好话我就不说了，浪费时间也没意义。我不同意的是DDD不适用于小项目，你说的一点我很肯定，就是DDD是设计方法，但是适不适合小项目要看DDD架构，DDD是适用于多架构的。当然小项目也许没有必要用DDD，但不等同于小项目不适合用DDD。 关于精炼我也有不同看法，精炼不仅仅是业务领域，模型或者设计元件的细分，剥洋葱的说法我不赞同。精炼是对模型的锤炼，是对业务深层次探索得出的。精炼不等于细化，而是聆听领域专家，是模型跟接近于现实中的业务领域。 我没有全部看完，大致上的看法就是这样，希望共同进步。 @ ImCoOLeR 刚看到。。。，这篇开始写的时候比较早差不多是14年写了大概，一直在草稿里15年发的，就现在来看，这篇博客里有很多不准确的地方，但是作为当年的学习的历程，所以不想改了 说不适合小项目大概是因为当时正在公司推DDD，也是一边学一边推，按部就班的落实到项目中，忽视了其实所有项目都是可以借鉴DDD思想的

回到目录 概念中的ＤＤＤ ＤＤＤ：　领域驱动设计，它是对面向对象的的分析和设计（ＯＯＡＤ，Object Orient Analysis Design）的一个补充，对技术框架进行了分层规划，同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心　，采用ＤＤＤ的设计思想，业务逻辑不再集中在几个大型的类上，而是在大量相对小的领域对象上，这些类具有自己的状态和行为，每个类都是完成的独立的，并与现实领域的业务对象形成一种映射。基于ＤＤＤ的架构设计，保证了系统的可维护性，扩展性和敏捷性，在处理复杂业务逻辑方面有着明显的优势！ 编程世界观的改变 以下信息是从http://www.jdon.com/ddd.html上拷贝的，写的很好，这确实是一种编程世界观的改变，而传传统编程观念完全不同 过去需求分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却 扭曲需求 ，导致客户运行软件后才发现很多功能 不是自己想要的 ，而且软件 不能快速跟随需求变化 。 　　DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。 　　DDD革命性在于：领域模型准确反映了业务语言，而传统的分层架构只关心数据， 这些数据对象除了简单读、写操作外

注：科比今天要退役了，我是 60 亿分之一，满腹怀念～😭😭😭 前几天看了园友的一篇文章《 我眼中的领域驱动设计 》，文中有段话直击痛点： 有人误认为项目架构中加入 Repository，Domain，ValueObject 就变成了 DDD 架构 。没错，我就是这样，不过准确的来说，并不能称为 DDD 架构，而是我之前经常说的“ 伪 DDD ”设计，后来我还抽离出了一个伪 DDD 设计框架： DDD.Sample ，大家有兴趣的可以瞧瞧，在实际项目的开发中，我用它做过了几个不太大的项目，我个人觉得用起来很顺手，当然并没有真正的 DDD 设计，只不过用了一个空的架构而已，然后冠以”DDD 开发“的名号。 因为之前有过 DDD 设计的痛苦经历（短消息系统），具体表现就是，如果真正 DDD 设计，需要花费大量的时间和精力，可能几天都在思考一个问题或者考虑几行代码的编写，但最后也可能没什么结论或结果，并且这个过程是很艰难和痛苦的，所以我后来就变懒了，懒的去思考项目所表现的业务，也不再考虑如何去设计领域模型，只是在考虑如何让框架用起来更爽，DDD.Sample 前两个应用的实际项目，我都是在完善这个框架，比如 Repository 和 UnitOfWork 的设计等等，所以，关于领域模型的设计，就是一堆贫血模型。不过，后来应用的第三个项目，也就是上一个实际项目，我觉得不能再这样下去了