DDD社区官网上一篇关于聚合设计的几个原则的简单讨论：文章地址：http://dddcommunity.org/library/vernon_2011/，该地址中包含了一篇关于介绍如何有效的设计聚合的一些原则，共3个pdf文件。该文章中指出了以下几个聚合设计的原则： 聚合是用来封装真正的不变性，而不是简单的将对象组合在一起； 聚合应尽量设计的小； 聚合之间的关联通过ID，而不是对象引用； 聚合内强一致性，聚合之间最终一致性； 上面这几条原则，作者通过一个例子来逐步阐述。下面我按照我的理解对每个原则做一个简单的描述。 聚合是用来封装真正的不变性，而不是简单的将对象组合在一起这个原则，就是强调聚合的真正用途除了封装我们本身所关心的信息外，最主要的目的是为了封装业务规则，保证数据的一致性。在我看来，这一点是设计聚合时最重要和最需要考虑的点；当我们在设计聚合时，要多想想当前聚合封装了哪些...

领域驱动设计之领域模型2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。领域驱动设计分为两个阶段： 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；由领域模型驱动软件设计，用代码来实现该领域模型； 由此可见，领域驱动设计的核心是建立正确的领域模型。 为什么建立一个领域模型是重要的领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点： 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分； 领域模型只反映业务...

消息场景：用户 A 发送一个消息给用户 B，用户 B 回复一个消息给用户 A。。。 现有设计：消息设计为实体并为聚合根，发件人、收件人设计为值对象。 三个问题： 实体最重要的特性是什么？ Message 实体是怎么得来的？ 发件人、收件人为什么不是实体？ 1. 实体最重要的特性是什么？《领域驱动设计》5.2 实体： 摘录一段：许多对象不是由它们的属性来定义，而是通过一系列的连续性（continuity）和标识（identity）来从根本上定义的。 归纳： 标识（identity） 连续性（continuity） 标识在实体中的另一种体现就是唯一和不可变，其概念在很多资料中有说明，这也是实体最重要的特性。 我有一个双胞胎哥哥，我们俩出生的时候，长得一模一样，以至于我们的爸妈都分不清，不得已他们在我们脖子上系个项链来标记：谁是老大？谁是老二？其实这个“标记”就可以看作是实体的...

REST围绕着资源这个概念而构建的，然后用URI来表示。然后一个HTTP动词和资源URI组合起来对指定资源进行HTTP调用来执行操作。大多数REST框架提供了指定资源名称的生成器，框架围绕着它来生成脚手架。不幸的是，许多这些生成器使用CRUD模型（Create,Read, Update, Delete）作为默认的起始点。资源被定义为一系列的属性，使用类似JSON Schema或某个具体语言的数据对象来定义，然后生成方法存根，然后来创建，读取，更新和删除该资源。 尽管这可以让开发人员觉得理解和开始工作变得简单了许多，是一个很好的起点，但是使用CRUD作为API的起点，我有一个很大的疑问。就是CRUD中的U是我最不喜欢的。让我们来谈谈U.通用更新方法允许客户端更新资源的任何字段，然后使用新版本覆盖现有版本。但是，如果允许客户端执行这样的操作，您的服务API在其使用的任何底层数据存储之上，...

我以前写过一篇关于领域事件的文章——实现领域事件，随着在项目中深入的使用DDD架构，我对领域事件有了新的认识。尤其是采用领域事件来解耦代码这种方式对项目的发展具有深远的影响。 我在实现领域事件中主要谈到了如何在技术层面去实现发布事件与订阅事件，比较了几种不同的方式以及它们背后的原理。但随着我在自己负责的项目中严格地实施DDD架构时，我发现如何去发布订阅领域事件的意义远没有决定去做这件事情本身重要。换句话说，与其纠结与是使用基于Spring的事件架构还是Guava提供的EventBus，是使用同步发布还是异步发布，还不如想想去做这件事情对你的项目会产生怎样的影响。 为什么要使用事件？我认为这是所有人应该考虑的首要问题。对我来说，使用事件的意义有两个方面，一是在于流程上的解耦，二是在于代码层面的解耦。在代码层面的解耦是显而易见的，我就不再赘述了。那么流程上的解耦是什么意思了？我们先看一下...

当你的系统或者业务变得日益复杂时，DDD的模式是一种非常值得尝试的架构模式。DDD让你更加关注于你的业务领域，思考你的业务模型，帮组你理清繁杂的业务关系。我推荐所有还没有了解过或者接触过DDD的后端工程师都去学习一下该架构模式。本文主要关注DDD中的领域事件，以及一种可能的实践方式。 我们知道领域模型的变化会产生领域事件。例如，用户在完成注册后，系统会发出一封带有确认信息的邮件到用户的邮箱；用户关注的好友发送动态后他会收到相应的通知等等。在业务比较简单或者不用考虑性能的情况下，我们可以直接把对领域事件的处理嵌入到领域服务中。考虑这样一个场景：用户回复了某条评论，那么被回复的那个用户（也就是那条评论的所有者）需要收到一个PUSH消息。这个场景比较简单，我们可能直接写出类似下面的代码： void reply(long fromUserId,long toUserId,String ...

关于领域驱动设计这篇文章参考了Eric Evans《领域驱动设计》一书以及Jimmy Nilsson《以C# .NET为例运用领域驱动设计和模式》，二者详细描述了领域驱动设计的核心概念、技术和模式。在某些情况下，直接使用这些书的措辞是有意义的，并且我认为Eric Evans和Jimmy Nilsson也允许我们这么做。 尽管将方法本身呈现出来是很有用的,但是仅仅对方法进行描述，DDD的许多微妙之处就会消失。这些方法应该是你的工具，而不是你束缚你的规则。它们是为设计而生的语言，在团队内沟通创意和模型十分有益。更为重要的是，记住实践DDD的目的是为了做出更加务实的决定。不要试图将一个方法强加于一个模型。另外，如果你“打破”了一个方法，确保你已经理解了这么做的理由，并将其与其他人沟通。 通常认为，DDD在面向对象范式下表现良好，但远不止这些。DDD解决了如何去理解问题空间这一挑战，甚至是更...

原文： http://static.olivergierke.de/lectures/ddd-and-spring/ 介绍这篇文章是的介绍一下领域驱动设计的基础构件、概念和Java的web应用（主要是基于Spring框架）之间的关系和区别。这篇文章的第二部分讲了怎么把实体、聚合根、仓储映射到使用Spring框架的Java应用中。 领域驱动设计Eric Evans的《领域驱动设计》无疑是软件设计领域最重要的几本书之一。这本书主要集中在软件开发中如何处理领域和软件的映射关系— 开始强调领域通用语言(domain ubiquitous language)，通过语言来提取模型，最终映射到一个可工作的软件上。我们已经对软件设计模式比较熟悉了，他是用于描述和提炼Class和Class关系的技术语言。而DDD是一种用于程序员和业务沟通的更通用的语言，使用DDD可以最终将代码映射到模型上。 基础...