DDD领域驱动设计

当面临确定对象是否满足一组特定条件的任务时，规格/规范模式(Specification pattern)可能是开发人员工具箱中必不可少的工具。当与组合模式结合使用时，组合规范成为一种强大的工具，可以解决任何复杂的业务规则，同时确保可维护性，健壮性和可测试性。在本文中，我们将看到如何在.NET

以领域为中心的架构是一种设计现代世界企业应用程序的新方法。

领域驱动设计（DDD）是一种软件开发方法：一组用于帮助开发复杂系统的技术，原理和模式。该术语是由Eric Evans在其2004年的著作《域驱动设计：解决软件中心的复杂性》中提出的。 通过无所不在的统一通用语言进行协作

这是著名DDD专家Nick在FlowCon France大会上的PPT演讲，要点：1. 一个松耦合软件架构与组织架构必须是匹配的，关键是在：持续交付效率和组织规模随着效率线性扩展。 2.一个社会技术工具集是能够更频繁实现软件交付和每次交付提

在JPA开发团队中，我们以领域驱动设计为参

大多数人进行SOLID软件设计讨论时都会很快变糟。我们最终为单一职责的“实际含义”而争辩或纠结，由于“开放/关闭”，我们某种程度上又需要抽象基类，并且由于“依赖倒置”，我们还向实体添加了接口。除了使您的代码“遵循SOLID”之外，还有更多重要的问题需要关注。此外，当您对“原则”非常“

企业正在迅速采用微服务架构来创建灵活，可扩展的应用程序，这些应用程序可以快速迭代，具有较高的容错能力和较低的停机时间。您如何构建正确的微服务架构？尽管确切的架构会有所不同，但是有一些最佳实践可以帮助设计有效和最佳的微服务架构。

我大约在三年前加入这个行业，当时还只是一个尚未毕业的数学家，后来转为ML实践者。我又花了两年的时间才找到自己的位置，在该职位上，构建软件是我的主要职业。第一手实战经验非常强大，但是一个人的时间有限。因此，书籍使我有机会学习其他从业者的精通技巧，这些都是经过数千个小时的工作而建立的。就

具有产品意识的工程师是对产品本身有很多兴趣的开发人员。他们想了解为什么要做出决定，人们如何使用产品以及热衷于参与做出产品决定。如果他们决定放弃工程学的乐趣，他们很可能会成为一名优秀的产品经理。我曾与许多优秀的产品工程师合作，并认为自己是这种开发人员。在生产世界一流产品的公司中，注重产品的工程

时间和资源是有限的，在开发软件系统时，我们如何花费有限时间并利用有限资源解决最根本、最困难的挑战？在我们可能要做的所有事情中，我们应该做什么，我们应该投资多少质量和严格度？对于软件工程师来说，自然的趋势是倾向于迎接最有趣的“技术”挑战。尽管并非总是如此，但我可以从自己的亲身经历中确认

领域概念建模对于我来说是一种很酷的练习，如同初学者区分动词和名词的练习，在副词和介词连用之处发现与获得更丰富的意义。也需要发现这些名词和动词根的约束限制与边界。目的是要消除隐藏的细微差别，并使它们在设计/代码中显而易见。阅读书籍，阅读业务领域的文档以帮助理解概念，以便您可以对

很长时间以来，我对公司组织软件开发团队的方式感到失望。我记得我还是一个年轻的，天真的软件开发人员，我曾假定会存在类似于设计软件架构的结构化过程和模式。我渴望结构和分析思维模式来设计最佳解决方案。令我感到震惊的是，经理们基本上根据他们的直觉来任意划分团队边界。这不是孤立的一家公

SAP是什么？为何价值$163B？每年公司在企业资源计划软件（通常称为ERP）上花费$ 41B 。如今，几乎每个大型企业都实施了某种ERP系统。但是，大多数小型企业通常不购买任何现成的ERP系统，而且大多数工程师可能没有看到过它们。ERP是公司存储其核心运营数据的地方，包括销

在经济高速发展时期，很容易做到技术业务的多样化。

DDD不是聚合、事件溯源、CQRS、事件风暴等。这些都是工具。它们已被证明在DDD项目中非常有用。但是我们必须小心，不要将演奏乐器与音乐艺术混淆。对我而言，这是DDD的关键是：与大型系统的复杂性作斗争时，项目团队如何获取领域知识，他们如何构建、开发和普及应用概念模型，以及随着时间的推

“企业资源计划系统”（ERP系统）之类实际上是一种瑞士军刀软件系统。毫无疑问，它们确实是功能强大的工具，但是在某些情况下，它们可能造成的弊大于利。因此，我想讲一个虚构的故事，该故事显示了组织如何陷入困境。为此，我将尝试使用Nick Tune的全新