问题标签 [bounded-contexts]

不太确定如何解决有关 DDD 的这个问题。

假设您有 2 个域：

• Product负责创建新的和管理Products一个人创建的现有的域。Product Aggregate Root
• 一个Store域，负责将所有创建的内容分配给要出售Products的给定对象，以及其他内容。Store但是他们Store也可以创建新Products的，将分配给自己，但也可供其他人使用，Stores以便他们可以分配Product给自己。Store Aggregate Root

AProduct可以存在而不属于 a Store。AStore可以在没有任何内容的情况下存在Products（我知道这没有任何意义，但这只是我正在处理 atm 的复杂解决方案的一个简单示例。）

因此，当 aPerson出现在系统中时，它们可以从任一端开始。他们可以从创建新的Products开始，也可以从添加新的Store.

这就是复杂的地方，当他们创建一个新的 时Store，他们可以选择添加现有的Products，或者他们可以创建一个新的Product并将其添加到Store.

你如何处理这个用例。是否Store有一个行为来CreateNewProduct负责设置新的Product然后将其添加到Store. 还是您只是在域Product之外创建一个新Store域作为域的一部分Product，然后告诉Storeto AddProduct/ AddExistingProduct？

更新：这样的事情是否适合作为Domain Service

我正在寻找一个问题的答案，即当我使用事件溯源时，如何使两个有界上下文最终保持一致？我的意思是我将一些值从一个上下文的实体复制到另一个上下文的值对象的情况。我知道我可以在值更改时使用域事件来获取通知，但是如何更新我的事件存储中使用这些值的所有这些聚合？很难通过 id 以外的任何其他属性从事件存储中查询聚合。

例子：

身份背景：

• 用户（id、用户名、密码、电子邮件）- 聚合根

讨论背景：

• Author (id,userame) - 值对象（这些值来自身份上下文）
• 消息（id、内容、作者） - 聚合根

I've made some small research about Domain Events, and have found few different solutions

• Udi Dahan solution, which handle events immediately
• Deferred domain events, which fire off in infrastructure mostly
• Domain Events which return result

Questions:

• Which one is a pure Domain Events ?
• Is it possible to have them all in the same project ?
• In that case how should I name and distinguish them ?
• Where to register EventHandler ? Someone mentioned that Application Service is appropriated place, but here I've seen that it was registered right into the Domain Model, and handled there, as well, and not in separate Event handler class.

One more extra question.

For example: When order is created and paid it has to get status "OrderPaid".

Because purchasing and ordering are two different contexts, right after Order was created we need to rise a Domain Event, which should be handled by Event Handler in Purchasing bounded context, but in result of Event Handling, there should be raised one more Domain Event - OrderPaid, which might be handled by Order context again. With monolith application it seems that one solution might be: pass Order object into Event Handlers to achieve expected behavior. Is there any other ways how to solve it, in such architecture style ?

我正在尝试基于现有的基于 C# WinForm 的系统对我的域进行建模，以提高我对 DDD 的学习，因此我整理了一个假设的概念模型来简化问题。系统本身没有一个典型的业务域，其中有很多逻辑混入到实体框架对象中，这些对象在系统的各个方面都被使用。我觉得这是一个大泥球（BBOM）。

我在工作中处理了一些 DDD 概念，但我想提高我的整体理解。我通读了 Evans 的蓝皮书“领域驱动设计：解决软件核心的复杂性”和 Scott Millets 的“领域驱动设计的模式、原则和实践”。以及观看有关该主题的无数视频，以及 Vaughn Vernon 的文章。我觉得这些年来我做了更多的数据驱动开发，这需要很长时间才能融入其中。

所以假设的系统是一个严格的质量控制系统，用于构建产品，它松散地遵循我所做的系统。

这是概念模型：

现在我看到了 3 个部分 - 不一定是有界上下文，但我正在努力确定这些有界上下文所在的位置。

业务流程分为3个部分：

1. 定义产品

为此，“用户”将输入包括名称在内的各种产品信息。作为其中的一部分，他们定义了产品应该是什么厚度以及它是由什么材料制成的。他们还将定义构建器需要使用什么过程来构建产品。它们还定义了是否需要进行外观检查和质量检查。

2. 构建产品

作为该过程的一部分，“建造者”将组装产品。但这仅限于建筑商的资格。Builder 符合基于厚度范围和材料的工艺的资格，因此业务规则仅允许选择 Builder，如果他们有资格获得介于工艺厚度范围和材料之间的产品厚度。

3. 检查

产品构建完成后，即可对其进行检查。作为其中的一部分，根据是否需要外观检查或质量检查类型，最新合格的“检查员”将能够检查产品。他们将通过或不通过检查。

作为这些流程的一部分，产品的状态将被更新。这将是：

• 未组装
• 组装好的
• 部分检查（已完成两项检查之一）
• 通过检查（所有检查完成）
• 检查失败（任何检查失败）

以下是有关域外系统的一些信息，需要深思熟虑：

• 该系统被设计为一个多用户，可以同时输入检查
• 可能在产品上输入的数据不正确，可以更正，这可能会使任何输入的构建和检查数据无效
• 然后将输入的数据用于各种报告中。

所以我需要一些想法：

1. 我的限界上下文在哪里。

2. 如何为我的聚合根建模 - 哪些数据应该是根以及我应该包含哪些实体/值对象。

   我是否只在有界上下文中包含我需要的域对象的数据 - 即不完全水合域对象。

3. 如何通过流程的不同部分实现一些计算状态的东西。

4. 如何处理数据输入错误的可能性以保持域数据正确。

我对任何存储库实现不感兴趣，只对纯领域概念感兴趣，尽管我们应该为每个有界上下文坚持什么的问题会对我有所帮助。

我担心有多个用户输入数据以保持产品状态的数据一致

下午所有

我目前正在学习领域驱动设计 (DDD)，但无法掌握基本概念。

模式原则和实践（Millett and Tune）

在我的学习过程中，我经常遇到域模型（DM）这个术语，但是它通常以不同的粒度级别进行讨论。

1. 在某些情况下，它表示为各种互连对象（客户、销售、报价、发票等）的工件（UML、草图、照片）的集合，这些对象概述了单个子域中的所有概念。

   这样一个子域只有一个模型

2. 在其他情况下，它表示为单个实体，例如Product，其中子域将由许多不同的域模型组成。

由于上述含糊不清，我很难理解域模型实际上是什么以及如何将这些模型放入有界上下文（BC）中

除此之外，我已经阅读了域模型可以在不同的有界上下文之间共享。

例如Employee在Payroll和HR Bounded Context之间共享

考虑到这一点，

1. 我会创建多个域模型来代表一个子域吗？
2. 还是只有一个？
3. 如果是后者，如何在上下文之间共享如此大的模型？

请有人能阐明这种歧义，并准确解释域模型是什么以及它的粒度如何。

非常感激

丹尼尔

我有一个带有应用程序服务的有界上下文，它使用 DTO 公开应用程序用例。

有界上下文还包括一个域服务，它公开了具有丰富域对象的域用例。应用服务是领域服务的“客户”。

最后，允许域对象持久化的存储库。

域中存在其他有界上下文，并且拥有有界上下文的团队之间的关系是客户/供应商，因此团队对齐相同的目标，并且可以合作将所需的用例公开给其他有界上下文。

在这种情况下，“客户有界上下文”应该在哪里连接到“供应商有界上下文”？

“供应商有界上下文”可以直接访问存储库或公开“供应商有界上下文”的丰富域对象的域服务吗？（在“客户有界上下文”中使用 ACL 来保护“供应商有界上下文”免于在域中泄漏）。我不确定这种方法是否良好，因为域重构会破坏所有 ACL 并需要维护。我知道这是 ACL 的目标，但是......

或者“消费者有界上下文”是否最好只连接到“供应商有界上下文”的应用程序服务，其中公开 DTO？（不需要 ACL）。我不确定这种方法是否良好，因为它强制应用程序服务模仿域服务仅作为访问点，即使用例显然是域用例。

有什么意见吗？任何人都尝试过具有好/坏经验的两种方法之一？

我没有从 Vaughn Vernon 的书或 Scott Millett 的书中找到明确的答案。

我正在寻找有关应用程序的某个目录结构的反馈。我意识到这并不遵循经典的堆栈溢出格式，其中存在“正确答案”之类的东西，尽管认为它仍然很有趣。为了提供有意义的反馈，首先需要了解一些上下文，所以请多多包涵。

--

我和我的两个同事创建了一个使用Clean Architecture的应用程序。对路由的 HTTP 请求被转换为请求模型，该模型被交给用例，然后吐出一个响应模型，该响应模型被交给演示者。

该代码是完全开源的，可以在 GitHub 上找到。我们还有一些文档描述了主目录的内容。

我们正在考虑重新组织我们的代码，并希望获得有关我们迄今为止提出的反馈。此次重组的主要原因包括：

• 现在我们没有一个好地方来放置不属于我们域的东西，但以某种方式绑定到它。例如授权代码，它知道捐赠 ID（授权不是核心域的一部分，而捐赠 ID 是）。

• 将有凝聚力的东西组合在一起很好。我们的捐赠代码是有凝聚力的，我们的会员申请代码是凝聚力的，而两者并不相互依赖。这与领域驱动设计中的限界上下文概念密切相关。现在这些上下文在我们的代码中并不显式可见，因此很容易使它们相互依赖，尤其是当您不熟悉域时。

这些是我们迄今为止确定的背景。这是一个初步列表，只是为了给你一个想法，而不是我想要反馈的部分。

• 捐款
• 会员资格
• 表单支持（电子邮件验证、IBAN 生成等）

我想要反馈的部分是我们考虑切换到的目录结构：

直接在上下文中的Authorization/文件夹将为我们当前在基础设施中奇怪放置的授权代码提供一个主页。其他不属于我们域的代码，但绑定到它，可以直接进入上下文文件夹，如果其中有一堆内聚/相关的东西，例如授权，则可以获取自己的文件夹。

我很高兴提供您需要提供有用反馈的其他信息。

我正在通过多个 Maven 模块开发一个解决方案来处理不同的有界上下文。

由于 Spring Boot，每个模块都公开了自己的 rest api，并且所有这些都托管在一个 maven 模块中，该模块具有一个由 @SpringBootApplication 注释的类。简化的项目结构如下所示：

在面对复合 UI 时，我尝试使用相同的模式：一个保留布局、静态资源的地方，同时，html 页面属于保存在其 maven 模块中的每个有界上下文。

问题是我在 spring boot doc 中发现没有办法从其他 jar 文件中提供静态资源。

是否有任何解决方案来获得此功能，或者这里是否存在任何架构错误？或者弹簧之外的东西（例如覆盖）是解决方案？

I am actually reading a book called "DDD in PHP", to help me understand the Domain Driven Design. So far everything is good, but I struggle to understand how to implement one specific topic without coupling Bounded Contexts: Domain Events

Let's say I have to BCs :

• Payments: Handles generation of invoices, sending them to the customers, etc
• Orders: Handles the creation of orders, their state, etc.

When an Order is placed, an OrderCreated Event is dispatched. The Payments BC catches this event with a subscriber, and creates the invoice.

The problem is, If I want to perfectly separate both BCs, where should the OrderPlaced Event live, since it's used by both BCs ? Should it live outside both BCs ? In both of them ? What if I want to deploy the Invoices module as a standalone, without having access to the Orders module, and its OrderPlaced event definition, would it cause some fatal errors ?

Thank you in advance for the answers !

我的应用程序代表用户在外部系统上自动执行一些操作。让我们将此应用程序的上下文称为 Inventory BC。

由于这是我的应用程序的主要特征之一，因此它被建模为域服务并通过反腐败层实现。到目前为止一切都很好。

此外，用户可能在我的应用程序将为他们处理的外部系统上拥有几个不同的帐户。所以我有一个单独的有界上下文，我将用户详细信息及其帐户 ID 保存在外部系统中。假设身份BC。

现在，Inventory BC 的反腐败层需要外部系统帐户 ID 和凭据。帐户 ID 是 Inventory BC 的一部分，用于分隔外部帐户和无法跨这些外部帐户进行的操作。但我不确定我应该在哪里存储凭据以及如何从 Inventory ACL 中检索它们。

我应该将凭据与他们的帐户 ID 一起保存在 Identity BC 中吗？然后我想我可以创建一个应用程序服务来返回给定帐户 ID 的凭据并从 Inventory ACL 调用它。

还是有更好的做法？

Edit1：另外，如果我要将所有上下文合二为一，什么是合适的？

Edit2：在我的外部系统域服务上，凭据应该是方法参数的一部分吗？还是我应该继续使用涉及 ACL 级别凭据的解决方案？