DDD聚合

如今，有关干净代码和体系结构的讨论很多。关于如何实现它的讨论越来越多。罗伯特·C·马丁（Robert C. Martin）描述的规则是通用的，我认为，我们可以在其他各种情况下使用它们。在本文中，我想让他们参考领域模型实现的上下文，这通常是我们系统的核心。我们想拥有一颗干净的核心，不是

聚合是领域驱动设计DDD中最容易被误解的概念之一，只是一堆实体和值对象吗？还是更多？什么是聚合？当然，这是领域驱动设计的核心模式……但这只是对象的集合吗？马丁·福勒（Martin Fowler）解释说： 聚合是数据存储传输的基

传统单体架构下的分布式事务概念并不适合微服务，面临的挑战很多(挑战问题点击标题见原文)，想在微服务中进行分布式事务处理？需要改变思路和视角：组合，如果您认为您应该合并几个微服务或将事务集成到一个服务中，那么进行此练习永远不会晚。（banq注：根据DDD有界上下和聚合的概念将需

问题：将责任分配给对象的基本原则是什么？解决方案：将责任分配给具有实现它所需信息的类。 在下面的示例中， Customer类引用了所有客户 订单，因此很自然地负责计算订单的总价值：

本文深入研究DDD和模型：它们是什么，它们之间的关系以及模型在领域驱动设计中的工作方式。 模型作为深入洞察的工具让我们首先解释DDD对模型的意义，因为它们位于DDD的中心。在系统开发中，“模型”一词意味着许

聚合这个词语由于非常广泛且通用，有可能导致很多人无法抓住其中心要旨，著名领域设计专家Mathias Verraes对聚合重新进行了一次定义：通过定义事务边界，并发边界和分发边界来强制一组相互关联的约束的一致性的架构模式。

目的用户对聚合器进行单个调用，然后聚合器调用每个相关的微服务并收集数据，对其应用业务逻辑，并进一步发布作为一个REST端点。聚合器的更多变化是： 代理微服务设计模式：根据业务需要调用不同的微服务。 链式微服务设计模式：

软件开发人员最常犯的错误是：把东西放在错误的地方。将本来应该分离的责任与概念耦合在一起。对我来说，这占据软件开发中95％。只是弄清楚*事物所属的地方。 其他观点：1. 我担心开发人员会强调并花费很长时间来决

在软件设计中，“越小越好”几乎普遍是坏建议，例如针对数据库分区，消息大小，μsvcs，有界上下文，类名，方法一致性等。一些关键业务逻辑会越过这些细粒度边界，并导致实施不当。小粒度事物看起来很简单，因为错误不是隐藏在事物内部，而是隐藏在它们的连接中。 事物边界会变大，很少变小或

软件不是孤立的工件。它必须嵌入到使用和生产它的人们的社会技术环境中，并与环境不断相互作用。我们需要知道的是，复杂的系统如何显示我们作为系统设计者试图捕获有用的抽象的行为。 “组织是动态的，层次结构化的实体。这种活力体现在每个组织级别的重大事件

2005:DBA: 我能控制数据的访问，确保安全和高性能；后端：我的ORM想抓什么就抓什么数据。 2018:后端：我的API设计能控制数据的访问，确保安全和高性能；前端：我的GraphQL想抓啥就抓啥数据。

鲍勃大叔推荐的Mark Seemann一文：昨天我拜访了一个客户讨论软件架构，包括DDD和ORM。今天我偶然发现了我在2014年写的东西。它仍然反映了我今天的想法。

我们都喜欢内聚，讨厌耦合（高聚合低耦合），关于内聚和耦合的标准建议是，设计应努力使内聚最大化并最小化耦合。这是一个很好的口头禅，但是在没有很好地理解真正意图的情况下，这常常是一种误导，或者被认为是学术上无关紧要的正确废话。一个简单的特征是，耦合是系统中各个部分的互连程度，而内聚是这些

问题：如何保持对象集中，易于理解，易于管理以及作为副作用支持低耦合？解决方案：分配责任，以保持凝聚力。用凝聚力大小来作为分配职责的判断标准。

目的有时在企业系统中，需要对传入的数据进行分组，以便将其作为一个整体进行处理。例如，您可能需要收集报价，并且在收到定义的报价数量后，您希望选择具有最佳参数的报价。Aggregator允许您根据定义的条件和参数合并消息。它收集原始消息，应用聚合策略，并在满足给定条件时释放合并消

将一小部分事件标记为公共事件，默认情况下保持其他事件为私有。(有界上下文内部时私有，有界上下文或微服务之间发送消息事件是公有，分成两个不同的消息主题通道) 问题领域事件 不仅可用于与其他有界上下文进行通信，