DDD领域驱动设计

这是一个完整的基于Spring Boot/Spring Cloud的领域驱动设计源码案例： ddd-by-e

今天，我们将讨论DDD意义上的标识与数据库主键之间的区别。 我们经常将两者混合在一起，但它们真的是一回事吗？实体标识在DDD的背景下，标识是实体固有的东西。 只有实体拥有它; 它是用于区别于所有其他实体的唯一标识它们自己的东西。例如，

这是一位使用DDD已经五年的经验分享：我最近一直在谈论领域驱动设计（DDD），无论是在聚会还是与客户，所以我想我会写下我的想法，看看它是否有帮助。现在，很多人都从技术角度撰写了有关DDD的文章，这是其他人的DDD，所以我不打算这样做，而是从非技术角度讨论DDD。

DDD（领域驱动设计）是一种软件设计方法的主张，这种方法非常全面，因为它提供了代码级别战术、项目组织级别甚至整个组织的战略级别的设计工具。Eric Evans 2003年的领域驱动设计：解决软件核心的复杂性为DDD奠定了基础。该本书认为代码应该反映业务模式，技术问题应在专用开发下不会

在关于DDD的每本书和每次会议中，我都听到“DDD不是银弹”。我可能是唯一一个反思的人。因此我可能会错过一些东西。不过，自从我开始学习DDD以来，我就在每个项目中使用它。即使在CRUD实现足够好的简单情况下也是如此。因为了解我的领域名并能决定CRUD是否能足够好地实现。

在我知道DDD之前，对于如何给类命名，我曾经提到过以下的想法。 如果我们用客户习惯使用的词语来命名类呢？这难道不让我们更容易向客户解释我们为他们实际建造了什么吗？ 当然，实际中有可能是完全错误的，但我想说我们与客

该文认为单体巨石架构如果经过良好设计也是很好的，但是什么是良好设计呢？原文： DevOps Days London今年很棒！会谈很有意思，文化包容性和友好性。 我一直认为我们应该建立'正确的服务'，而不是为了用'

很多MVVM的问题通常是相同的：什么应该是模型，什么应该是ViewModel？我们不能真正责怪开发人员，因为在线参考文档不是很好，特别是

昨天，Explore DDD 2018刚刚闭幕，DDD作者Eric Evans在探“持怀疑态度，乐观态度和实用主义”主题演讲中表示，“DDD尚未完成。”，很多人认为DDD诞生于15年前，以为不再是新技术了，其实，从领域驱动设计这本书出版以来的十五年中，人们不断在探索创新，事件风暴建模、事件溯源和CQ

DDD最大的挑战绝对是战略设计部分，即如何划分有界上下文正确和构建领域模型。很难用语言表达清楚，我认为最好的方法是更多练习，并从大师那里学到更多东西，例如，尝试Event Storming。之后，如果团队没有任何领域驱动开发经验，请不要低估技术部分的挑战。和很多人说技术部分不

DDD原则是开发软件需要从业务需求开始。通常倾向于关注技术细节，但通过这种模式，设计基于核心业务目的和逻辑，同时可考虑到公司的战略方向。企业应用程序可能非常复杂，因此我们的团队使用了一种将用户（领域专家）连接到需求定义的开发技术，目的是构建可转换为解决业务需求的软件。在本文中，我想分

从技术角度来看，我认为DDD项目只不过是划定一个清晰且受保护的领域。虽然我在处理大量遗留代码，但我发现常见的DDD错误是无法准确识别领域内的内容以及外部的内容。 您的数据模型不是您的域模型将数据模型用作领域

“做正确的事;做正确的事”在我脑海中有机地出现。简单的CRUD项目变得越来越不能胜任，程序员的速度很难提升，他们的工资也很难提升。我急于解决这个问题。然后有一天我看到了这样一句话：我选择做一件事不是因为它很简单，而是因为它很难。我对这些话很有动力，我不能停止思考“简单”“复杂”的“麻烦”。然

\“仅在复杂域中使用DDD”,这是DDD专家用来避免回避“是否银弹”争论的口头禅，这样至少可以避免不愉快的争论。但是我们想知道到底什么是复杂的域？这样才能知道何时使用DDD。 从战略角度来看，我们可以随时使用DDD，剩下的问题是：我应该何时

这是一个DDD的PPT，大概意思如下：1. DDD适合所有人：软件工程师产品所有者业务专家顾客用户 2. 发现边界不同领域，不同解决方案统一语言作为指南进行有意义的讨论