DDD聚合

为什么组合好于继承？

本文使用亲身案例形象说明了软件设计领域为什么组合Composition要好于继承（包括接口继承），只有需求分析域的问题分解，才有设计编程的组合应用。来自游戏公司GameSys的Yan Cui发表了博文：

Go语言是彻底的面向组合的并发语言

面向组合编程从AOP的Mixin，然后到Ruby的Traits，直至DCI设计，包括Scala的trait的组合设计，这些都有一个共同特点，组合特性是显式的，也就是说要用专门语法来声明组合。其实组合设计应该是面向对象设计中很自然的一种方式，也就是说，只要你使用面向对象语言，隐式上你就具备了强大的组合

使用Builder模式的三个理由

1.帮助你实现DDD聚合设计如果创建一个对象的属性是通过使用外部服务实现，这是比较容易，没有任何问题。但是，如果该属性是在创建该对象的同一个方法中来创建，那么就有了问题。在这

具体例子求解,异步后数据弱导致的决策失误问题

最近看了 cqrs和lamx.采用富领域模型 ,event source. 异步操作. 这个有个bad case, 我不知道采用什么方案解决. 钱有100,两口子之前有约定要剩下90. 老公看到有100,花10元,花完以后因为事件异步,数据不一致,此时老婆刷新页

单元测试中的“单元‘如何定义？

很多人做过单元测试，可能对单元定义没有较真过，其实普通小名词蕴含大概念。 Martin Fowler在其

高内聚、低耦合的个人理解

我们在进行软件设计，都是希望达到高内聚、低耦合的目的，但在实际工作中我发现很多程序员没有仔细去想什么时候应该高内聚，什么时候应该要低耦合，而且很多人对这句话更多是关注低耦合，而不是高内聚，感觉只要有依赖就不好，结果造成一些不合理的强行分离，导致写代码时出现不少麻烦。其实，我觉得高内聚、

ORM和Rails的问题

看到一句英文：ORM变相鼓励你抹去许多对象的相关状态，而Rails则鼓励你耦合任何一切。原文：An ORM encourages you to smear related state across a lot of objects, and th

经典DDD + CQRS＋ES　的一些疑问

以下是我关于经典DDD的简单理解：在经典的DDD中，大量使用领域服务 Domain Service 和 Factory 来修改聚合根。复杂的聚合根创建使用 Factory，将Factory 所需的参数全部传进去，Factory内部进行资源调配，包括逻辑验证，仓储 Repository

为什么需要强调创建一个小的聚合

是由于什么原因我们需要创建尽量小的聚合

聚合根的使用

比如，用户有很多种，微博用户有微博nick，getNick，银行用户可能就只有getID，那么在一个系统内部，多个用户聚集在一起，按照聚合根的说法，是由聚合根getUser（）吗？那么聚合根里就会有很多这样的getUser。是否合适？那他跟资源库又有什么分别呢？因为我可以直接从资源

在模型的两个聚合中如何重用对象

在聚合1中，对象A是一个实体对象，在聚合2中，对象A是一个值对象，这种情况，在模型中该如何设计？是为聚合1，聚合2分别定义对象A，还是他们可以重用同一个对象A？例如，在汽车这个聚合中，因为需要对每个轮胎进行跟踪，所以需要区分这些轮胎，因此，在汽车聚合中，轮胎是实体对象，在这个聚合中，它们需要

问个问题跟DDD相关的问题

在DDD中两个BoundContext中的Agg是如何交互的？如果采用事件进行交互，那么在一个UnitOfWork中，事件源Agg的属性状态发生了多次变化，最后uintofwork提交时可能有变化也可以没变化，此时假设有变化的情况下；那么此时是发出一个事件还是多个事件，那些属性变化的临时值是有有必要