DDD领域驱动设计

Russell Ackoff博士是著名系统思想家，他的观点对于复杂系统DDD和架构设计都有借鉴意义：解决问题的方法： 忽视：忽略问题并希望它会消失 通常解决方案：根据先前的经验和定性判断解决问题。这就是“令人满意”——做得够多

根据我的经验，将软件开发重点放在重用上是错误的。相反，专注于重构文化：这不仅会产生质量越来越高的更简单的软件，而且随着时间的推移，重用将以模式和框架的形式出现。 众说纷纭：只有当我们注意到我们一次又一次地做同样的事情时，重用才会出现。 重用应该是一种重

微服务于10 年前出现，是软件中发生融合进化的例子之一。虽然这个词可以归功于全球软件顾问Thoughtworks 的James Lewis和 Martin Fowler （banq注：这个词应该首先由亚马逊提出，也就是著名“一个披萨”，开发一个微服务的人员正好够吃一个披萨 ，MF只是进行了微

早期面向对象设计OOAD是通过发现名词来发现寻找对象，今天，我们不提倡使用名词发现法来简单地模拟现实世界中的事物，现实要复杂得多。找到好的对象意味着识别属于应用程序域及其执行机制的抽象。他们与现实世界事物的对应充其量可能是微不足道的。即使在对领域概念进行建模时，您也需要仔细查看这些对象如何适

领域驱动设计是一门软件设计学科，其核心原则是： 复杂领域的软件要求所有设计人员（工程师、测试人员、分析师……）在领域专家的指导下对该领域有深入的、共同的理解 这种理解植根于语言：领域语言应该被形式化为一种无处不在的语言（共享、一致、明确） 理解表达在专家和设计

事件风暴与事件建模都是DDD建模方法，两种方法提出发明者不同，切入点不同，虽然都是以领域事件为抓手，eventmodeling.org原文如下：事件风暴EventStorming分为设计级别或流程级别，需要一些 DDD 知识，像“聚合”或“有界上下文”这样的词，对于非技术观众来说有点

当前项目组合：EventStorming BP/PL（领域探索）+用户故事映射（故事发现、确定优先级、划分为更小的故事）+ BDD（规范）+ EventStorming DL（设计）+ BDD/TDD/DDDtactical（DDD战术设计、实施）。势不可挡！ 

如果您想学习或练习如何将大型企业分解为多个领域并将其用作软件架构和团队组织的基础，nick的个战略性的领域驱动Github项目可能会很有

这是关于应对Complicated和Complex的方法：砍伐树木和修剪树篱之间的区别是：来自 Sonja 的一条推文，她说：“我喜欢修剪树篱与砍伐树木的类比。当您决定砍伐一棵树时，您不能半途而废并改变主意。但是在修剪树篱时，您可能会从一个想法开始，但您可以在进行过程中改变主意并修改

这是一个实用指南：结合DDD和OOP展示如何通过封装构建意图暴露一个类的API？这篇博文中的所有代码都可以在这里找到。对我

我想在这篇文章中强调的是，我看到很多团队在发现领域后陷入困境，不知道下一步该做什么。这里概述了我使用的一般方法：绘制域图，确定可能的演变，构建故事，如果您试图将 DDD 方法引入您的组织，请使用 DDD Exemplar 。通常，公司希望将对其产品的改进与对其运营模式和工作方式的改进

“一个实体在内聚上最通用含义是：当其各部件之间的因果相互作用强于部件与其环境之间的因果相互作用时” ... 来自动力系统理论“An entity is _cohesive_ in the most general sense when the causal interactions

从领域原语构建的正确领域模型会迫使我们开发人员做正确的事情。让我们想出一个简单的 Java 方法签名示例：String foo(String str);这段代码有什么作用？签名只告诉我们它是一个方法：它对输入字符串执行某些操作，或者它

具有讽刺意味的是，强调无处不在的语言的 DDD 社区搞砸了这么多预先存在的DDD术语：DDD聚合Aggregate这个词语准确吗？“聚合”完​词语可能​全过载。DDD社区意见领袖mathias将其视为“确定性单位”，它是某些数据和规则的一致性边界，在此边界内，您具有原子性、无