标签: bounded-contexts

我已经开始学习DDD的原理了,我现在正试图掌握有界上下文的概念.特别是,你如何决定它有多大(或小)？是的,我知道,尽可能小,必要的大(根据Vaughn Vernon).

假设我要为博客建模.然后我可以说有3个有界的背景:1)Front Page(以最新的文章为特色,没有显示评论)2)讨论(包括评论的单篇文章)3)Article Composer(我撰写文章的地方).

然而,这感觉不对(无处不在的语言对所有人来说都是一样的),似乎我是从前端角度来看,我仍然在考虑视图模型或其他东西.

有谁能请我指出正确的方向？

我实际上正在读一本名为“DDD in PHP”的书，以帮助我理解领域驱动设计。到目前为止，一切都很好，但我很难理解如何在不耦合有界上下文的情况下实现一个特定主题：领域事件

假设我必须BC：

• 付款：处理发票的生成、将其发送给客户等
• 订单：处理订单的创建、订单状态等。

当放置时，将调度Order一个事件。OrderCreatedBCPayments通过订阅者捕获此事件，并创建发票。

问题是，如果我想完美地分离两个 BC，那么OrderPlaced事件应该在哪里，因为它被两个 BC 使用？它应该住在两个 BC 之外吗？在他们两个中？如果我想将 Invoices 模块作为独立部署，而不访问 Orders 模块及其 OrderPlaced 事件定义，会导致一些致命错误吗？

预先感谢您的答复！

我有一个相当大的数据库,大约有80个左右的表.所以我决定将表分成有界上下文,而不是在一个大的edmx文件中包含所有80个表.

所以我有像销售,客户等有限的背景.

我的客户edmx文件中有我的主要客户表.但是,我还需要从Sales edmx上下文的customer表中访问某些字段,而不是所有字段,但只需要1或2个字段(例如,我只需要客户名称,而不是整个客户对象/表).

我是否必须将整个客户表添加到Sales edmx文件中？这种情况的最佳做法是什么？

我对 DDD 的概念相对较新，并且发现有很多示例解释了如何为相对简单的场景定义有界上下文，但似乎没有涵盖的一个领域是主数据和参考数据。

我指的参考数据类型包括货币代码、国家/地区代码和计量单位，它们将用于确保仅使用有效值。

我所指的主数据类型是诸如客户和产品之类的实体，其中不需要不同的有界上下文具有自己的实体视角。我知道在某些情况下，发票有界上下文中的客户实体与运输有界上下文中的客户实体不同，但出于此问题的目的，我们可以假设发票和运输都需要完全相同的客户数据。

我的问题是，在具有多个有界上下文（例如 ERP 系统）的应用程序中，主数据和参考数据是否应该在公共有界上下文中定义，或者这些实体是否应该在每个有界上下文中重复，即使它们包含完全相同的数据？

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

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

parent  
|-- pom.xml  
|-- ...
|-- host   
  |-- Application.java      
  |-- resources
     |-- index.html
|-- driver
  |-- api     
  |-- resources
     |-- register.html
|-- notify
  |-- ...
|-- passenger
  |-- ...

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

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

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

鉴于我有两个微服务：服务 A 和服务 B。

服务 A 拥有完整的客户数据，而服务 B 需要这些数据的一小部分（它通过一些批量加载从服务 A 获取）。

这两种服务都将客户存储在自己的数据库中。

如果然后服务 B 需要与服务 A 交互以获取额外的数据（例如 GET /customers/{id}），它显然需要一个在两个服务之间共享的唯一标识符。

因为 id 是 GUID，所以我可以在服务 B 中创建记录时简单地使用来自服务 A 的 PK。所以两个 PK 匹配。

然而，这听起来非常脆弱。一种选择是将“外部 ID”（或“源 ID”）存储为服务 B 中的一个单独字段，并使用它与服务 A 进行交互。这可能是一个字符串，因为有一天它可能不是 GUID。

是否有围绕此的“最佳实践”？

更新

所以我做了更多的研究，发现了一些相关的讨论：

您应该在 REST API URL 中公开主键吗？

在 REST API 中向客户端公开数据库 ID 是一种不好的做法吗？

作为主键的 Slug

结论

我认为我试图在服务 A 和 B 中保持客户的两个主键相同的想法是错误的。这是因为：

1. 显然，PK 是特定于服务实现的，因此它们可能完全不兼容，例如 UUID 与自动递增的 INT。
2. 即使您可以保证兼容性，尽管这两个实体都恰好被称为“客户”，但它们实际上是两个（可能非常不同）的概念，并且服务 A 和服务 B 都“拥有”自己的“客户”记录。您可能想要做的是在这些服务之间同步一些客户数据。

所以我现在认为任何一个服务都可以通过自己的唯一 ID（在我的例子中是 PK GUID）公开客户数据，如果一个服务需要从另一个服务获取额外的客户数据，它必须存储另一个服务标识符/密钥并使用它。所以基本上回到我的“外部 ID”或“源 ID”的想法，但也许更具体为“服务 B id”。

我对如何定义它们之间存在共享问题的有界上下文以及如何使用域实体来表示它感到困惑.

例如:客户在客户上下文中有许多产品公司具有公司上下文中的产品列表

因此,客户通过客户上下文管理,公司通过公司上下文管理

鉴于上下文有不同的模块.

如果我想用产品提供公司的地址详细信息,应该如何处理？

我是否在包含客户的模块中引用包含公司上下文的模块,或者在客户上下文中创建公司实体,以便在与客户交互时使用？

谢谢

我有一个WinForms应用程序,我希望将重构为使用DDD架构.首先,我试图真正地围绕建筑本身,我有埃文斯的书,我有弗农的书,我发现自己正在努力应对我将面临的三个场景.我担心在概念设计过程中我可能会过度思考或过于严格.

1.)利用DDD的Pluralsight教程中提供的示例,发言者指出不同的有界上下文应该由他们自己的解决方案来表示.但是,如果我有一个不面向服务的winforms应用程序(这最终会改变并且很多问题变得毫无意义)这似乎不可行.因此,我假设我将把它们分成不同的项目/名称空间,保持警惕没有相互依赖性.这是考虑它的正确方法还是我错过了一些明显的东西？

2.)我有一个导航UI,它启动其他模块/窗口,这些模块/窗口属于不同有界上下文的单独表示层.想想在启动ERP应用程序时打开的第一个窗口.由于这不适合任何特定的BC,如何正确实现这样的事情.这应该属于共享内核吗？

3.)我有一个工作管理有限的背景和评级/成本计算有限的背景.创建作业时,业务流程的一部分是对其详细信息进行评级.这有自己的UI等,我觉得这个演示文稿仍然充分属于作业管理环境.但是,这些细节的实际评级过程绝对不应该.我不完全确定如何与评级/成本核算相关联,因为bc要彼此分开.我意识到我可以做消息传递,但对于非分布式应用来说,这似乎有些过分.每个BC都可以自己托管某种API,但这似乎有点过分,尽管这会让团队很好地在以后迁移到分布式架构.最后,我的最后一个想法是拥有某种共享依赖,这是一种各种事件存储.我不知道这是否与Domain Events相同,因为它们本身似乎有一个单独的问题.那么,这是否意味着这将属于共享内核或其他类型的解决方案？

先感谢您.

我找到了这个代码示例.

https://code.google.com/p/ddd-cqrs-sample/

似乎非常完整和井井有条.不是"框架",只是一个具有非常精细和明确的方式来做事情的示例项目.但是,不完整.这带来了一些疑问.

他们擅长回答你的问题.通过https://groups.google.com/forum/#!forum/ddd-cqrs-sample查看他们的Google论坛

好.事实是,他们在SALES BC中拥有客户,在CRM BC中拥有客户/潜在客户.我想我们都同意指向同一个"人".假设在销售漏斗中,该人员作为潜在客户开始,然后通过购买使他成为客户的东西成为客户.

我的问题是,为什么他们有三个分离代表同一个"人"？难道不能像"共享内核聚合"吗？我不知道这样的事情是否存在.有点困扰我在数据库Client/Customer/Leads中有三个表用于相同的"东西".此外,在示例中还不清楚(CRM未实施)您如何在BC之间进行通信.我阅读了他们的文档,但我找不到任何有价值的线索.

这个过程怎么样？假设您需要为此潜在客户/客户/客户添加一个地址来发送订单.你会选哪一个？我想在Shipping BC的ShippingAddress？用Id指向？顾客？客户？您应该直接将地址添加到客户吗？例如直邮,因为它与Shipping没有任何关系？

我将我的系统分解为(至少)两个有限的背景:学习设计和调查计划.

在研究设计背景下有一个名为"主题"(面试的潜在主题)的概念.我们还维护该领域的受试者和人群之间的关联.

现在,在调查计划中,我们还需要(一些)关于该主题的信息(例如:用于计划访问,或者甚至用于预期选择的问卷,以防该受试者所属的人口事先已知).

所以,在这两种情况下我都需要这个"主题".

我应该采取什么方法？有一个共享内核,正如Eric Evans DDD一书中所解释的那样？我不介意(至少现在)让两个上下文共享同一个数据库.

或者......我应该去纯粹的微服务吗？含义:这两个不能/不应该共享数据库...,在这种情况下,我可能必须通过事件传递去镜像/复制路由:https://www.infoq.com/news/2014/11 /共享数据-有界上下文

对于上述情况,有关哪一个更好的想法？

谢谢!