DDD战略设计与领域建模

领域驱动设计中有一个重要方面很少被提及。我认为这是 DDD 最重要的方面，但是如果您在网上搜索“领域驱动设计”，您不会找到它。这件宝藏一直隐藏在人们的视线中。这是 Eric Evans 的 DDD 书第 8 章中的 Share Pie 故事。(Share Pie是一种投资组合份额策略

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

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

将大型复杂系统模块化为更小、更易于管理的部分是很好的最佳实践，不仅可以降低每个部分的认知负担，还可以实现团队独立性和操作弹性。棘手的一点是如何划定边界？为整个系统建立一个稳定和可持续的结构。基于有界上下文的领域驱动设计是一种方法，其中是使用领域语言作为指导，另一种方法是从业务模型定义

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

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

2002年，亚马逊的杰夫·贝佐斯发布了一份备忘录，该备忘录已成为技术行业经典。这份备忘录被称为“API Mandate”（API授权执行书），通常被视为亚马逊技术声明，因此受到技术人员的广泛钦佩，并被高管完全忽视。这很不幸，因为可以毫不夸张地说，API 3Mandate彻底改变了亚马逊作为一

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

有关大数据通常观点是：给我一个聪明的数学家、技术工具和大量数据，我可以毫不费力地创造营业务意义。但是，这种一种危险：很多被认为有业务意义的假设前提都是不确定的（逻辑前提都是错的，第一性根本不存在），而且在大数据分析中经常将相关性与因果关系混淆的，这种大数据方法受到了各个领域专家的广泛批评。<

统计学是机器学习的四大支柱之一，另外三个是线性代数、微积分和概率。要在机器学习或数据科学方面表现出色，你应该掌握的一件事是统计学。在这里，我用例子写了常用术语。统计分为两部分，分别是：描述性统计:探索数据（尚无观点）。了解我们拥有什么类型的数据，我们拥有多少样

很多人将操作系统、芯片等看成是核心竞争力，这些还是战术层面，供应链的建设才是真正战略核心竞争力，本文分析了全球供应链两个巨头：亚马逊和SAP，供应链是将消费市场和生产制造厂商链接起来的唯一桥梁：软件帮助公司协调维持全球市场的供应链。代码是如何工作的——它隐藏了什么？供应链管理

当我们开始用事件建模我们的系统时，我们很容易掉入陷阱。我们习惯于从数据模型的角度来看待我们的功能：当你手里拿着一个关系数据库时，你会看到到处都是表格，因为

Russell #Ackoff 有一些很棒的见解，但我认为我最喜欢的是他谈到做一件错误的事情对我们没有真正的帮助。正如他所指出的，“你看到我们主要致力于把方向错误的事情做对（南辕北辙），这是非常不幸的，因为错的事情你做得越正确，你就会变得越错误，而在正确的事情上我们做错了时，我们只是犯了一个

DDD建模设计中，必须提前了解* 未来产品和* 对现有产品/服务的计划增强可以揭示我们如何建模以及我们应该如何对给定系统建模的新见解。 假设一家人寿保险公司建立了系统。这都是关于人寿保险的。好的

使用Wardley Mapping讲故事需要一种完全不同的方法。通常，您的听众不了解映射，也不熟悉这些模式。第一个建议是从空白画布开始。空白的画布没有威胁性，它是一个空洞的东西，没有任何信息，但承诺了一些新的和令人兴奋的东西。你可以用一张空地图消除很