在域驱动的设计中，使用工厂在域层中创建域对象似乎是一种好的做法（而不是使用直接构造函数或IoC） 但是在presenter层中使用域对象工厂怎么样。例如，假设我正在根据从演示者获得的用户输入创建一个域对象 这里有一个例子，假设我有一个配置域对象，它有许多十进制设置 公共类配置：PersistantObject { } 为了在域层而不是presenter层中创建此对象，我必须将这些十进制值作为函数参数传递。创建笨拙的函数定义和调用 ie ConfigurationService.CreateCon

在领域驱动设计中，具有标识的对象是实体是一个常识。例如，任何人都有几种形式的身份（姓名等） 但价值对象是那些没有标识的对象。一个常见的值对象是address，但address没有标识。但是在数据库层，我们可以有一个复合密钥。这个概念在DDD中有效吗？它将通过道路名称、邮政编码和门牌号（省略城镇和城市等信息）的组合来识别地址。金钱将是另一个价值对象 区别似乎在于没有单个可识别字段的对象，而值对象往往不属于实体。例如，“我”（替换为我的名字）可以穿鞋子等，但“我”不是鞋子、衬衫等（） 这是正确的思考

通过重播EventStore中的事件，特别是当事件可能触发其他事件发生时，我正在努力弄清楚在重建模型时应该发生什么 例如，购买了10件商品的用户应被提升为首选客户，并收到一封向其提供特定促销的电子邮件 显然，我们不希望在每次为该用户重建模型时都发送电子邮件，但当我们重播第10次PurchaseMadeEvent时，如何阻止这种情况发生？当您重播事件时，您并不是在重播生成这些事件的所有域逻辑。通常在域方法中，您将引发一个事件；然后，该事件的引发应该会更新该域对象的整体状态 例如： public c

我有一个问题，如何处理一个传奇故事的决策 取决于在传奇创建之前发布的事件 下面是一个例子来说明我的问题： 假设我有一个客户和一个订单。当客户机 创建验证过程开始时，该过程的结果是 客户无需特殊费用即可自由消费的订单金额 授权。我不会详细介绍这个过程，因为 这是断章取义的。计算金额时，将发送一条命令 将计算出的金额和CustomerAR发送给CustomerAR 发布具有该值的事件（CustomerMaxOrderAmountEvent）。所以 很好 几周后，客户下了订单。订单是 创建并开始我的O

我正在努力进行以下领域设计，这些领域设计不符合我所理解的DDD概念 一方面，我将设备->传感器->测量层次结构建模为一个集合，设备作为根，传感器作为实体，测量作为VO。到目前为止还不错 现在，每个设备都有一个类型，传感器也是如此。同时，测量指已测量的变量（例如温度）。这里是事物分裂的地方 我最初将类型建模为值对象，但类型集有限，许多设备和传感器共享相同的类型 然后我决定将它们建模为一个聚合，遵循与设备聚合类似的结构：DeviceType->SensorType->Variable。但是，这不起作

我创建了一个基础设施，这是我们全新的内部网项目，并尝试遵循几乎所有的最佳实践。我还想提到，这是我第一次从零开始创建架构 目前，我的基础架构的第一个版本已经准备就绪，并且运行良好。但我想在下一个版本中实现有界上下文结构 我试图解释一下目前的情况 DbCore:负责数据操作。首先使用的是实体框架5代码。只有一个DbContext类和其中定义的所有数据库集。还基于以下接口实现了GenericRepository模式和工作单元模式 IGenericRepository public interface

埃里克·埃文的DDD书，第152页： 仅为实际需要的聚合根提供存储库 直接访问 一,。 不需要直接访问的聚合根是否应该通过需要直接访问的聚合根的存储库进行检索和保存 例如，如果我们有Customer和Order聚合根，并且无论出于何种原因，我们不需要直接访问OrderAR，那么我假设获得订单的唯一方法是遍历Customer.orders属性 二,。 icCustomerRepository应在何时检索订单？当检索到CustomerAR时（通过icCustomerRepository.GetCus

我有几个聚合：存款、取款等。现在有一个VO称为分类账，它还有其他相关VO。分类账标记了存款和取款的交易，这两种交易都会发生。在这种情况下，它似乎类似于创建一个单独的聚合（创建一个文件夹并将分类账和相关类型放入其中）。但DDD不允许这样做，因为聚合根只能是实体 可能的解决办法是什么？在DDD边界内，我如何分类和放置分类账和相关VO 更新： 分类账就像一条记录，是每项操作的一笔交易。例如，当存款完成时，交易已经发生等，因此它没有状态，只保存一次，不再修改。它是为了保存记录而保存的 存款和取款都有状态

在允许用户向服务付款的特定领域中，支付授权是一个不可分割的部分，但从技术上讲，支付授权可以设计为一个独立的组件，根据一些先决条件和传递的信息授权支付 在这种情况下，支付授权应该是子域（支持域）还是仅是支付子域中的有界上下文

我的同事告诉我——我们没有业务逻辑，我们只有像GetById、GetBySearchTerm、GetByParentID这样的CRUD……所以我开始对这些词感到疑惑 在阅读了DDD之后，这些方法都是CRUD，它们有一种基于特定代码（通常是SQL）获取数据的机制（还包括存储、更新、删除…） 如果业务分析师告诉我：“我们需要显示有关特定客户的数据”。 在我看来，这是（GetById）一个业务流程，GetById应该放在应用程序的业务逻辑部分中，它会联系存储库以获取数据。使用CRUD方法的存储库负责根

我有一个问题，我不知道该怎么办 我的域名： 我有一个预订实体，预订业务背景的根源。 在预订中存在事件的集合，即用户创建的真实事件列表预订看起来有点无用，但整个系统将预订链接到其他实体，因此它确实是业务的根源。 事件可能有文本注释，因此我创建了一个注释实体。我使用实体是因为注释可能会随时间而变化，它们链接到一个事件，无法共享注释实际上绑定在预订业务上下文中，并聚合到预订根实体 表单（创建事件）： 我有一张用来提交“事件”的表格。实际上，表单的数据生成了一个命令，其中包含创建新的事件所需的所有信息，

我正在我的一个项目中练习DDD，这是我第一次与DDD互动。我有一个系统，它有三种不同的用户，一种是厨师，一种是送货员，还有一种是普通用户。厨师是一个可以为自己的食谱做广告并接受订单的概念。送货员是一个注册用户，只负责将食物送到各自的地址，而普通用户则是一个想要订购食物的用户 据我所知，这三类用户属于3种不同的有界上下文，而不是“用户管理”或“身份管理”。如果我错了，有人能纠正我吗？如果没有更多的信息，这是不可能的，但这里有一些提示 如果您考虑CRUD“有界上下文”，例如“用户”、“厨师”、“送货

假设有两个微服务：A和B。每个都有自己的数据库 A有一个具有此方案的数据库： { "id": "unique id for the user", "name": "the name of the user", "email": "the email of the user", "address": "the address of the user" } { "userId": "unique id for the user", "email":

我们可以为通过Axon框架创建和使用的事件/消息中的成员变量设置公共设置器吗 据我所知，事件是过去发生的事情，使它们在概念上是不可改变的。因此，我们不应该有公开的设定者 有人能帮我确认一下吗？正如你所说的那样，事件是“过去的事情”，这意味着它们已经发生了，你应该让它们和它们的内容保持不变 因为它们是Java类，所以您可以创建setter，但从事件源的角度来看，您不应该这样做

我读了一本书 在源代码中，实体对象执行所有CRUD操作。这意味着实体对象直接从方法调用存储库 评论指出： 持久性绝对是域对象的责任 这是正确的吗？“持久性是一个基础结构方面，域层应该与之解耦”：我引用了你提到的文章 持久性由存储库实现处理。域对象应该不知道自己属于这样的存储库 在回答你的问题时，我可以说没有正确或错误的做法，但这种说法是有争议的。如果您的项目以一致的方式进行，并且您对该方法没有意见，那么这可能是一种最佳实践。在我看来，域对象应该不知道持久性问题，因此从纯粹的DDD视图来看，该语句

我理解我们不应该直接更改聚合根的子级，而是应该通过聚合根上的方法来执行。 例如，order.SetOrderLineQty（产品，数量） 但是如果聚合根的子元素是抽象的东西呢？ 假设您有一个汽车聚合根目录，其中包含一个IWheel列表作为聚合的一部分。您将如何通过其聚合根添加/更改车轮的属性（谁不知道车轮的具体类型） 一个更真实的例子是： 医生可以创建MedicalReport（聚合根），其中包含IMedicalNote列表（作为MedicalReport聚合的一部分）。 IMedicalNot

聚合中非根的实体可以保存对根聚合的引用。或者是根聚合只能保存对其子实体的引用。聚合中的实体可以保存对聚合根的引用 聚合中的实体也可以包含对其他外部聚合根的引用 外部对象不能包含对聚合内部实体的引用。外部对象只能引用聚合根，不能引用内部对象 应仅从查询/存储库返回聚合 聚合应创建为一个完整的集合，通常使用工厂。聚合中的实体可以包含对聚合根的引用 聚合中的实体也可以包含对其他外部聚合根的引用 外部对象不能包含对聚合内部实体的引用。外部对象只能引用聚合根，不能引用内部对象 应仅从查询/存储库返回聚合

域实体可以通过服务层接口调用或应用服务层吗？也请告诉我怎么走？简言之，不 域实体不应该知道应用程序服务层。应用程序服务层的工作是协调域对象之间的操作，必要时跨越有界上下文 根据我的经验，这是一个非常严格的规则，所以如果你觉得需要打破它，那么你可能会遇到更高层次的设计问题

我想知道我的表示层的结构是否可以作为设计聚合根的线索 让我们有一个实体ProjectEntity及其相关实体ProjectMemberEntity（1:M） 该页面的结构如下所示： 页面顶部是ProjectEntity的表单 表单下面是一个网格，显示ProjectMemberEntity的列表 如果要添加新的ProjectMember，用户必须转到该页面并单击位于网格标题中的“添加新成员”按钮。编辑和删除也具有相同的相似性 我想知道这种行为/“页面结构”是否可能是对聚合根（projectenti

正在寻找一些关于与RavenDB一起使用auth捆绑包的帮助或博客文章 使用HelloWorld示例： 我正在尝试禁用用户查询订单。。我尝试过不同的auth角色方法，但我无法让这该死的东西工作 目前我已经： *创建了一个授权用户 *创建了一个授权角色 Id: Authorization/Roles/Orders { "Permissions": [ { "Operation": "order/1", "Tags": [

我已经阅读了一些关于getter和setter的使用，以及它们如何帮助克服域模型对象中封装的目的的文章/帖子。我理解不使用setter背后的逻辑——您允许客户机代码在对象业务规则和不变量的上下文之外操作该对象的属性 现在这个原则仍然让我困惑。例如，如果需要更改对象的成员变量的值，会发生什么情况？例如，如果一个人的名字发生了变化，我如何在模型中反映这一点？起初我想，为什么不使用一个名为“ChangeName”的函数，让我传入新名称，然后它可以更改内部“name”变量。好。。。。那只是个二传手，不是

我试图使用Java建模中的颜色和原型 此外，我还尝试合并DDD最佳实践，现在假设我们有一个人扮演两个角色 在我的应用程序中说客户和患者 客户角色用于CRM范围内的上下文，患者角色用于医院管理范围内的上下文 我的角色类可以使用弱id访问人员详细信息，弱id是唯一表示人员的值对象，可以找到此方法的详细信息 现在，在党的地方，事物原型指定的职责之一是列出党所扮演的角色的能力 鉴于角色存在于不同的有界环境中，我们如何做到这一点 因此，理想情况下，客户和患者不应与个人存在于同一个有限的环境中。从我提出问题

我没有使用任何ORM。因此，我正在讨论“Save”方法是否实际上属于业务域实体，还是应该在将移交给业务域实体进行保存的某个服务中进行抽象 e、 g class员工 { 字符串名； 出生日期； GetAge（） { } 保存（） { } } 或 class员工 { 字符串名； 出生日期； GetAge（） { } } SomePersistenceService { 保存（员工emp） { } } 因为这个问题被标记为“域驱动设计”，所以您需要一个存储库来为您解决这个

我有一些大实体。实体具有“Id”、“状态”等属性。 我有此实体的存储库。 我想更改一个实体中的状态。 我应该获取整个实体、更改属性状态并在存储库中使用save方法，还是应该在存储库中使用方法ChangeStatus（id，newStatus）？可能您不需要域模型。您可以尝试直接使用SQL更新数据库 当且仅当您需要雇佣专家了解业务时，您才需要域模型。 否则的话，就是太贵了 顺便说一句，如果您有大型实体类，其中包含在大多数操作中不需要的数据，那么您知道您没有正确定义 有界上下文的最佳定义是Evans

我正在努力找到以下问题的最佳解决方案。我需要确定一个国家是否为“因努斯”（例如，当前由地址引用） 我在NHibernate中映射了以下简化模型： class Address { public Country Country {get; set;} } class Country { public List<Address> Addresses {get; set;} bool IsInUse() { return Addresses.Any(); }

我试图在个人项目中实践领域驱动设计。我有一个示例域，我正试图在有限的上下文中划分它 我几乎可以肯定我知道怎么做，但在定义了它们之后，我开始对它们感到不确定 我怎么知道它们定义得很好？我如何判断自己是否做错了？不幸的是，没有办法判断。没有规则来确定有界上下文是否正确。你必须利用你对该领域的知识和经验（通过一些尝试和错误）到达你需要的地方 即使是在BC中建模，您也会发现在进行过程中需要重新考虑一些选择 如果你感到不确定，那么这可能是一个信号，它可能是不正确的，或者你需要更多的经验在该领域。您甚至可能

我正在开发一个遵循领域驱动设计技术的系统，我的目标是捕获员工的打卡时间。一个要求是，系统不能允许同一员工在给定的时间跨度内连续使用两个时钟。我的问题是这个规则在哪里更合适，我不认为它与一个实体有关，而是作为域实体之上某种过程的规则。建议 您可以使用域服务来处理此问题。您可以让应用程序层获取当天的所有时钟，并将其提供给域服务。或者，如果IRepository位于您的域层，域服务可以请求时钟输入。您可以使用域服务来处理此问题。您可以让应用程序层获取当天的所有时钟，并将其提供给域服务。或者，如果IRe

我有一个相当大的聚合根实体，名为Alert。创建警报时，会发生一些复杂的事情，因此它们会被捕获到业务流程模型中，并在BPM引擎中执行（例如，“处理警报”流程）。有关警报的各种数据集可由多人独立添加/更新，所有人都在同时解决警报（例如，BPMN流程中的并行用户任务） 如果没有警报，此数据对业务没有任何意义，如果没有警报，它将无法存在 但是，由于此附加数据是在警报在业务流程中移动时添加的，因此它感觉像是单独的“实体”。这将防止在多人将其工作保存到业务流程时，单个警报聚合根目录上也出现版本错误 问题:

假设我们有一个类Order（与用户相关），它有属性state。我想防止在同一时间有多个已确认订单，因此在我确认任何订单之前，我必须检查在其时间段内是否已经有一些已确认订单 我可以采用两种方法（我知道）： OrderRepository有一个功能changeState，该功能在更改之前搜索冲突的已确认订单，并且仅在未找到任何内容时才允许更改-这里的问题是存储库知道更改状态的逻辑 orderepository被注入到Order中，Order具有函数changeState，该函数将使用该存储库检查冲突

我有一个设计问题，这是扭转了我的想法，因为一段时间以来，我没有找到一个很好的解决方案。这是关于CQR和域边界的 让我们假设我有一个上下文，它是关于为一个系统进行预订，以及随后的事件。该系统允许将单个预订链接到单个事件（已经完成，没有问题），并将每周预订链接到一系列事件。每周预订是在确定一周中的某一天完成的（额外数据不相关）；每周预订总是有开始和结束日期（半年） 系统还有两种类型的工作日：正常工作日和非工作日，在这两种情况下，活动无法举行 作为一项业务请求，用户希望在每周预订时，系统单独取消在非工

什么时候应该使用数据库驱动的开发，什么时候应该使用域驱动的开发，谁能给出好的答案呢。这两种发展方法在各自受人尊重的领域都有其重要性。但我不太清楚哪种方法适合哪种情况。有什么建议吗？首先，马丁·福勒在他的《企业架构模式》一书中描述了三种不同的“模式”。事务脚本、活动记录和域模型。DDD使用域模型模式作为总体架构，并描述了许多实现和设计该模型的实践和模式 事务脚本是一种没有任何分层的体系结构。同一段代码读取/写入数据库、处理数据和处理用户界面 活动记录比这更进一步。分离UI后，业务逻辑和数据层仍然在

我用春天，冬眠为我的生命。对于更新，我调用repo.findById（id）获取当前实例，然后调用model.setXXX（）更新字段，最后调用repo.save（mdl）将其保存回来。对于删除，我调用repo.remove（id），现在我的更新和删除都是状态驱动的，可能会导致我的模型发生状态更改，有时，根据状态，某些操作（如删除）是不允许的。我如何实现这些行为，以使这些逻辑基本上在域模型中，并且不会泄漏到存储库实现中？我会这样做： // entity class User{ ... b

我刚开始进行领域驱动设计，我的领域有一个项目，其结构如下： 领域 /实体 /界限 /用户故事 正如我所理解的DDD，除了外部世界与域通信的边界之外，域中的一切都应该是不可见的。我所看到的域内实体类的所有示例都有一个公共访问修改器，例如，这里有一个名为Message的实体： public class Message { private string _text; public string Text {

您可以将类不变量视为健康标准，它必须 由操作之间的所有对象实现。作为先决条件 因此，在类的每个公共操作中，都可以假定 类不变量保持不变。此外，它可以被假定为 类不变的每个公共操作的后置条件 持有。从这个意义上讲，类不变式充当一个通用的 加强教育的先决条件和后决条件 课堂上的公共操作。有效的前提是 与类不变量结合的公式化前提条件。 同样，有效的后置条件是 后置条件与类不变量一起使用 1.如果在服务器上定义了类不变量类： a） 先决条件通常是根据被调用操作的形式参数来表示的，所以类不变量如何加强方法

当我看到我们的办公室时，我立刻想到了一些实体和价值对象 例如，post-it块中的一个空post-it肯定是一个值对象，因为它无法与同一块上的任何其他空post-it区分开来，如果我需要一个空post-it，我根本不在乎我使用哪个post-it 相比之下，我和我的同事肯定是实体，因为我们每个人都有自己的身份 一个表可能是一个实体或一个值对象，这取决于您看待它的方式（它是任何一个表都和其他表一样好，还是您的表？） 当然，YMMV 所以，现在我已经找到了一些实体和值对象的真实类比——聚合的类比是什么

假设我们有两个简单的域对象： 主题实体->消息值对象 根据DDD原则，这两个域对象可以包含在一个聚合中 但在某些情况下，如果只想显示主题列表，我们需要检索没有消息的主题，有时我们需要检索带有消息的主题 设计这个简单箱子的最佳方法是什么？提前感谢。我建议您将域逻辑与演示所需的数据分开。类似于命令查询分离CQS或命令查询职责分离CQR。例如，如果有人向主题添加新消息，您将创建一个适当的命令，并将其作为域逻辑的一部分进行处理。若您需要在用户界面中显示一些数据，那个么可以通过DTO数据传输对象只选择您真

我开始设计一个具有域驱动设计和洋葱架构的控制台应用程序，在此之前，我想探索一个具有域驱动设计和洋葱架构的完全设计的应用程序。如果您遇到任何类型的示例，请将链接发布到它。我与您有相同的问题，并得出以下结论：您不会找到完整的DDD示例，因为它不存在 一个合适的DDD应用程序将尖叫域而不是框架。当您查看代码时，您将看到一个会计系统或调度系统，而不是DDD系统 我建议您从实体、聚合根、应用程序边界和存储库开始，逐一实施每个部分。当你陷入困境时，寻找解决具体问题的方法 更新 我找到了沃恩·弗农的这本书 不

我正在开发一个简单的基于DDD+事件资源的应用程序，用于教育目的 为了在存储到事件存储之前设置事件版本，我应该查询事件存储，但我的直觉告诉我这是错误的，因为它会导致并发问题 我遗漏了什么吗？根据您正在考虑的用例，有不同的答案 通常，事件存储是一个哑的、不知道域的设备。它表面上类似于一个列表抽象——它存储了您在其中输入的内容，但实际上它不做任何工作来满足您的域约束 在您的事件流只是已发生事件的持久记录的用例中，这意味着：您的域模型没有否决权；记录事件不依赖于以前记录的事件，那么附加语义就可以了，并

问题 AR是否可以发出自己的命令，或者最好通过侦听外部命令发出的事件的处理器发出命令 BTW:< /强>如果你认为这个问题会导致“主要固执己见”的答案，我仍然想知道它是否被认为是一个好的实践，以及为什么。 PHP代码示例 类PatchableComponent扩展了EventSourceDaggerGatteroot 实现实体、可重构EventSourceDaggerGetRoot { ... 公共静态函数importFromCore（…）：可修补组件 { $patchableCompone

在源于事件的环境中，例如Ruby toolkit，聚合根目录有一个明确的功能：设置、编译数据和发出事件。如中所述 由该聚合根（例如一个位置）发出的事件将发出一个PlaceAdded事件 然后，订阅的处理器确保将记录添加到查询数据库中的投影表中。例如，表中建议的位置 在应用的另一侧，即cqr的Q部分，存在可以执行的查询；e、 g.LatestProposedPlacesQuery将从Proposed_places表中返回一份建议地点列表 到目前为止的设置，我也不相信这是完全正确的 现在，我想知道上

在CQRS和DDD中，聚合是事务边界。因此，我一直以这样的方式对命令进行建模，即每个命令始终只处理单个聚合。当然，从技术上讲，可以编写一个处理多个聚合的命令处理程序，但它不在单个事务中，因此不一致 如果您实际上必须处理多个聚合，我通常会使用流程管理器，但这有时会让人感觉开销很大。此外，据我所知，流程管理器总是只对域事件作出反应，而不是直接通过命令来处理。因此，您需要决定将起点放在哪个聚合上 我已经看到一些人使用所谓的域或应用程序服务来解决这个问题，这些服务也可以接收命令，然后处理多个聚合—但在这

最近读完了Eric Evans Domain Driven Design（信息量很大，非常有趣），但这是自完成本书以来的第一个主要项目，并且遇到了如何处理域模型保存的问题 我很欣赏服务/存储库的使用，以及它们如何帮助模型，但它们将如何处理模型保存 我以前的域模型保存将遵循以下方法调用结构 父类。保存 { ParentClassDB.Save ChildObject1.保存 ChildObject1DB.Save ChildObject2.保存 ChildObject

只是想让小组思考如何处理实体的配置细节 我特别想到的是可能会被管理员更改的高级设置。最终，您可能会存储在app或web.config中，但从DDD的角度来看，应该在对象中的某个位置显式设置 为了便于讨论，让我们以基于web的CMS或博客应用程序为例 给定的博客条目实体具有任意数量的实例设置，如作者、内容等 但您也可能希望设置（例如）默认描述或关键字，如果作者没有更改，则站点中的所有条目都应以这些描述或关键字开头。当然，您可以在类中创建这些常量，但是站点所有者无法更改默认值 因此，我的想法如下：

我开始在DD的世界，并试图建立一个足够简单的应用程序。我有一些关于如何选择对我的领域建模的问题 我的应用程序允许用户订购贺卡。 用户可以一次订购任意数量的卡。 选择要订购的卡片时，他们浏览卡片目录。然而，卡目录不是本地存储的，而是从外部系统检索的，但是，如果他们希望添加到订单中，他们在当前会话中浏览到的每一张卡都将在该会话的生存期内本地缓存在数据库中 当他们向订单中添加一张卡片时，它会进入一个新的订单行项目。然后，他们必须为订单行项目、颜色、问候语等指定一些其他细节 我的问题是： 如何在我的域中

我有这样的设计： 一个产品有许多定价网格，一个网格有许多定价周期 Product Id Name Grids[] Name Periods[] Price Start End 现在我有特别优惠，当卖家创建一个优惠（例如-10%）时，他可以选择将其应用于产品甚至网格（例如，他不想将优惠应用于网格“www.apartnerwebsite.com”，但他更喜欢将其应用于网格“我的网站”） 但我不能这样做，因为没有网格ID，也不能引用根聚合中的叶。在我看来，网格是自己的

我读过，在大多数情况下，值对象不应该引用其所有者 a） 我的解释是，关联应该是单向的，只能从所有者到VO进行遍历 b） 为什么VOs不应该提及他们的所有者 谢谢这是一种代码气味，可供参考其所有者，因为它表明违反了以及。根据定义，值对象是一个除了保存值之外几乎不做其他事情的对象。因此，它是不可变的，没有大多数逻辑（业务逻辑、生命周期逻辑等）。我遵循这一原则，因为我希望我的POJO设计独立于使用它们的客户机，并在代码级别将其与客户机分离。这样，它们就变得便携了 a） 我把这理解为，联想应该是 单向，

a） 我有点困惑，在大多数情况下，我们应该只拥有一个工厂来生产整个聚合，还是应该拥有一个工厂来只创建聚合根 b） 构建整个聚合的工厂应该自己构建根对象和非根对象，还是应该将非根实体/VO的构建委托给其他工厂 因此，如果Aggregate包含5种不同类型的非根实体，那么Aggregate factory应该自己创建这些非根实体，还是应该有另外5个工厂（每个非根实体一个工厂），哪个Aggregate factory将委托创建特定类型的非根实体 谢谢你埃里克·埃文斯的DDD书，第138页，用粗体写着：

我有一个聚合根叫做Person。此人也有地址。这些类别之间的关系是多方面的（许多人共享同一地址） 这意味着，当我使用工厂创建具有特定地址的新人时，我必须检查数据库中是否已经存在相同的地址，并为用户使用现有地址 这要求我的工厂能够访问地址存储库（或直接访问数据库）。允许这样做吗？如果不是的话，有什么更好的方法可以做到这一点 //编辑 我的解决方案如下： 我有一个类PersonService，它持有注册一个人的逻辑。方法register（）已经获取了由AddressFactory创建的Address

我的订单聚合根目录能够发出几个事件，例如订单创建，订单支付，订单取消。按照建议，将所有类型的订单事件存储到单个卡夫卡主题中，并将orderId作为消息键，这是一种好的设计吗？或者我应该为他们每个人创建一个单独的主题 拥有单一主题的好处是保持了事件的顺序，但消费者需要在事件结束时过滤一些事件。第二种方法的优点是消费者更简单，因为他们可以订阅他们需要的确切主题，但构建顺序需要订阅多个主题，而他们不是按照正确的顺序来自卡夫卡，因为他们来自不同的主题 谢谢我不确定是否有对/错的问题，但这是我的两便士：

我有以下对象，事件为聚合： public class Event { private List<CheckIn> _checkIns = new List<CheckIn>(); private List<Guid> _checkInRequiredFields = new List<Guid>(); public List<Registration> _registrations = new List<R