DDD领域驱动设计

该文是Salesforce的软件架构师Pat Helland于2016年12月发表的针对其在2007年CIDR（创新数据库研究会议）上首次发表的同名文章的更新和缩写版本。他曾经发表“不变性改变一切”。 业界谈到分布式事务通常指两段提交2PC事务(Sprin

软件编写有时候难以在预算内按时完成的其中一个原因是，缺少对领域专家所说的对商业语言的关注。大多数时候，确认需求意味着将理解的需求映射到某种关系数据模型。然后，构建业务逻辑以在持久性层和表示层之间隧道传输数据，并在此过程中进行必要的调整。虽然并不完美，但该模式仍然使用了很长时间，而日渐增加的复杂性使得

为什么人们开始谈论“事件流”、“无损数据捕获”、“领域驱动设计”、“CQRS”？ 让我们尝试剥离技术，让我们看看下面谎言背后的真相：软件其实是沟通(software is communication)Con

上周我参加了DDD欧洲会议。这是第二版，它在阿姆斯特丹举行，我住在那里。我工作公司Werkspot赞助了我的入场票，所以我还想要什么？ 嗯，其实我希望一个好的会议，实际上它就是！非常有经验的开发人员都发表了演讲：Vaughn Vernon，Udy Daha

日常编程中你使用过状态机吗？也就是状态模式？首先问题是为什么要使用状态机，解答这个问题必须回答如何对抗软件的复杂性？软件的复杂性是因为一份代码做两件事引起的，很多领域模型中都包含一个半残的隐晦的状态机，如果不将状态管理从领域模型中分离出来，相当于让领域模型做两件事，一件事代表实体属性，一件事表达实体

node.js cqrs 框架为增加 DCI 特性，加入了一些启动 code ，以后的对象，将是数据与行为根据场景，动态结合的对象；从而完成 CQRS + DDD + Actor + DCI 的有机整合，为开发大 中小 项目提供强大的核心支持，分布式／微服务，或普通的 react 应用 （cqrs将

本文您推荐采取三个领域驱动的步骤，能使您的代码库变得更易于管理 毫不讳言，在单体(整体/铁板一块monolith)架构中编写代码是容易的。我们可以随时直接查询数据库，在应用程序的其他部分调用我们想要的任何功能，而不必考虑整体架构组织，因为我们正在向现有架构

该文认为实现微服务最难的部分是业务数据，对于复杂业务的微服务系统必须结合领域驱动设计、事件驱动和EventSourcing等。 微服务中数据状态一般是放在数据库中，微服务是根据分离关注然后封装的设计原理，因此，每个微服务应该拥有和控制自己的数据库，并没有两

一位有着10年面向对象语言的程序员对面向对象两大支柱继承和封装提出了自己的疑问，并由此认为可以向面向对象说再见了。 原文：

最近在动手做一个CQRS 和 event source 结合的微服务项目。实施过程中。遇到了一个跨服务关联查询的问题。虽然现在还没有确定究竟哪里会遇到。但是我知道自然而然肯定会遇到的。比如USER 这个service和其他service之间的跨服务关联查询。这样的话。就会产生一些问题。网上找了一些相

无意中看到2007年一篇有关SOA分布式事务的英文：Distributed Transaction Mana

六角形架

这是一本使用PHP实现的领域驱动设计DDD免费英文在线书籍。主要使用PHP语言演示了DDD中指对象、实体和领域服务以及领域事件以及聚合 工厂和仓储等概念。

规则：创建一个对象时，它应该是一次性完整的、一致的且有效的创建好。 说白了，对于Java来说，一个类只应该有一个构造函数，这样才能保证一次性完整一致地创建它的对象。看看Matthias Noback有关DDD这篇文章怎么说，下面是一半翻译一半掺杂我个人观点

本文是一篇微服务和单体架构比较文章，这类文章很多，但是比较的现象背后其实已经假设了一种先验的判断标准，这篇文章的言下之意是微服务比单体高级，对人员素质要求高，其实这是一种误解，微服务正是首先承认人理性设计能力不够，才用行动替代设计，先分成两三人的突击队上前线摸清敌情，相比单体的总体规划，然后再切分上

如题，仓储是否需要缓存领域对象，即每次从仓储里拿出领域对象都是同一个对象而不是每次都从数据源中构造一个新对象，此处的缓存是指JVM的内存，不是Ehcache或者Memcache等。请大家指教。另外问一下，如果需要缓存的对象里有其他无法缓存的资源怎么办？比如我的领域对象对应现实世界中的一个特殊