我最近开始熟悉 DDD 概念和 CQRS，我意识到 CQRS 中最重要的概念之一是除负载平衡、NServiceBus 等之外的 DDD，但我很好奇我们是否可以单独使用 DDD 概念而不在 CQRS 复杂性中使用它开发和创建我们的项目。
据我所知，这是一种通过将实现连接到不断发展的模型来满足复杂需求的软件开发方法。我需要知道单独使用 DDD 或与 CQRS 一起使用的项目规模应该是多少。
最佳答案
作为@expandable 答案的补充:
CQRS、聚合、事件溯源等只是工具。经验表明它们在 DDD 项目中运行良好。使用这些工具并不意味着你做 DDD。
DDD 是关于通过开发人员和领域专家之间的对话提炼出一种无处不在的语言。在这些讨论中，您会注意到某些单词根据上下文具有不同的含义。
例如，您可以考虑在线零售商店(如亚马逊)的产品生命周期。与领域专家讨论后，您可能会发现产品根据购买的生命周期具有不同的含义。对于零售环境，产品与价格和描述有关，而在运输环境中，重要的是目的地地址以及产品的尺寸和重量。
这是使用两种语言并且您可能必须为每种语言(零售和运输)创建有界上下文的线索。有界上下文表示使用一种语言的领域的一个区域。当语言单词的含义开始改变时，上下文边界就会出现。
开发人员和领域专家讨论后确定的有界上下文需要与代码库保持一致。对于此示例，您可能会创建一个用于零售的包裹和另一个用于运输的包裹。有界上下文的实现通常是相互分离的。例如，每个有界上下文都有自己的具有不同属性的产品类。
每个有界都可以根据需要拥有自己的架构:CQRS、事件溯源、六边形等。但是，您应该注意您选择的架构是否与有界上下文的域保持一致。例如，如果您的域本身不是基于事件的，您可能不会使用事件源。
关于domain-driven-design - 领域驱动设计概念和与 CQRS 的关系，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55758568/