DDD领域驱动设计

DDD关键是发现有界上下文(bounded context)，事件风暴(Event Storming)和领域故事(Domain Story)是两种不同的查找上下文边界方法，他们之间有什么异同？ Eric Evans在他的“领域驱动设计”一书中称他们

作为其业务逻辑的一部分，微服务通常不仅需要更新自己的本地数据存储，而且还需要向其他服务通知发生的数据更改。发件箱模式描述了一种让服务以安全和一致的方式执行这两项任务的方法; 它为源服务提供即时“读取您自己的写入”语义，同时提供跨服务边界的可靠，最终一致的数据交换。如果你已经构建了几个

DDD带给了我们(包括我)很多软件开发的乐趣。当你能够领域分解分析时，后面的实施就变得容易了，它会导致一个简单，可维护且易于理解的代码，将比开发团队本身更长久。自DDD发布“蓝皮书”以来，DDD已经走过了漫长的道路，但根据我的经验，没有多少人意识到DDD是一个不断发展的，不断拓展的东

今天的企业应用程序无疑是复杂的，需要依靠一些专门技术（持久性，AJAX，Web服务等）来完成他们的工作。作为开发人员，我们倾向于关注这些技术细节，这是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没用，无论它看起来多么漂亮或者如何很好地构建其基础设施。

刚开始在一个项目中使用DDD Big Picture Event Storming可能会很混乱，这里描述一个详细的议程和一个案例简报，保证其在正确的轨道上实行。

我们是开发者。我们需要与技术保持同步。每天，我们都学习编程语言，框架和库。我们所知道的现代工具越多越好。与Angular，React，Vue，Riot，Ember，Knockout保持同步很有趣。 但是我们在浪费时间。

各位好，我现在正在开发一个电商项目，目前还是使用的事务脚本形式，最近也在接触DDD，这几天一直在思考商品上下文中领域模型的设计，有几点问题想请教大家， 先描述一下业务场景：1. 商品分为统一规格和多规格， 统一规格用户无需选择商品规格，直接输入售价、库存（目前库存只是作为sku的一个属性）等

Eric Evans：主题演讲（“上下文中的语言”）：从基础知识开始（单词在上下文中有意义;当我们明确指出这个上下文的边界时，我们最终得到一个有界的上下文），Eric讨论了两个主要的主题：大泥球，以及微服务上下文中有界的上下文。 banq注

这是来自一篇生产实践的经验分享，程序员对技术热情，而不是对业务理解的热情会误导企业软件方向，导致很多挫折和失败，技术不是越新越先进越好，而应该匹配业务领域：“优秀的程序员对他们的工作充满热情”基本上是我们行业的常见现象。总的来说，这可能是真的，但最近我一直对“编程的热情如何妨碍我们为

2018年6月26日，我很幸运地被DDD巴黎团队邀请与一些DDD明星同台演讲，如Mathias Verraes，

我们总是倾向于不同意域和子域这样的基本术语的定义。在这篇文章中，我想大声思考并概述我对这个主题的看法。这些看法基于我在我们公司长达7年的DDD之旅，它对我有用。我相信它也可能对你有用。 领域Domain“领

让DDD为你的JavaScript混乱带来秩序。我不会把自己当作JavaScript开发人员，我总是开玩笑说这是一种我从未打算学习的语言。它现在如此普遍，它刚刚发生。我经历了享受它和鄙视它的阶段。但是通过爱的高峰和低谷并不是很讨厌。一个问题仍然存在：如果我要成为一名优秀的JS开发人员

领域驱动设计是一种解决跨学科交流问题的软件工程方法：由于开发人员和专业人员使用不同的术语，因此存在相互理解问题。这首先是业务语言问题（不是编程语言），DDD通过为开发人员和专业人员提供一套用于理解的规则以及因此基础领域的通用模型来帮助弥合这一障碍。

来自Kamil Toszek一篇DCI与DDD结合的文章：我正在实践领域驱动设计方法，它有一些很好的部分比如有界上下文（模块分离很好 - 每个模块代表上下文边界），还有一些 - 对我来说 - 不是那么好的部分：领域富血模型。DDD说实体的功能应该是该实体的一部分，这导致具有许

让我们做一个小实验：试着向那些对此毫无头绪的人解释领域驱动设计的要点。这一点，特别是简洁地说，并不容易。哎呀，我自己也在努力。有界的上下文，实体，域事件，值对象，域，聚合，存储库......为了在明显的混乱中找到顺序，我想从一个相当不同寻常的角度分析DDD方法 - 将领域驱动设计应用