问题标签 [bounded-contexts]

I am trying to find a best way to work using Entity Framework and found a recommendation to not have a big models (separate them by intent) because it can make application more complex to maintain and can have an impact on performance

According to Julie Lermans course at Pluralsight.com it is possible (and recommended) to separate models (contexts) using Code-First approach, but how can I do it using Model-First approach? Is it possible?

Any suggestions?

我们试图找出一个场景的分离的有界上下文集成。

假设一个上下文是Document Core Bounded Context (BC)，它有一个Document Entity 和Author。在实现 DDD 书中使用IdentityAccessContext BC将用户、组和角色分隔到他们自己的上下文中是有意义的。

正在发生的问题是在考虑获取 100 多个文档的列表时。

假设 Document Core BC有自己的实体来标记文档的作者。

然后身份BC有一个具有相关信息的用户。

获取文档列表时，应该如何将来自IdentityAccess BC的信息检索到文档作者/与文档作者一起进行显示（例如全名）？

似乎有几个选择：

1. 也许是一个从两个表中获取数据的反腐败层？
2. 在两个BC中重复用户的全名?

两者都感觉不太对，因为 #1 需要加入来自 2 个 BC 的数据（在某种程度上），而 #2 需要在更改用户名时可能更新几个 BC。

关于这个还能做什么？（如果重要，使用 C#、MVC、NHibernate）清楚地获取对象列表并稍后获取例如作者的姓名和其他数据是不现实的。

然而，在查看BC集成时，鉴于 RPC、域事件和 RESTful 服务集成一书中提到的 3 个选项，至少后 2 个在应用程序是 MVC 的情况下没有意义，它直接使用2 BC 作为类库，它们都使用相同的数据库。可以通过 Identity BC 的应用程序服务直接从 MVC 更新用户信息。可以根据需要更改数据库和 BC。

假设我有两个有界上下文，即Shipping Context和Billing Context。这些上下文中的每一个都需要了解客户。

在数据级别，客户由CustomerTbl数据库中的表表示。此表包含描述客户的所有必要列。

中的列CustomerTbl（简化）：

• Name
• PhysicalAddress
• PaymentMethod

Shipping Context与Nameand相关PhysicalAddress，而Billing Context与Nameand相关PaymentMethod。

在运输上下文中，我对聚合进行了建模Recipient：

• RecipientName现在具有和的属性/值对象PhysicalAddress

在计费上下文中，我对聚合进行了建模Payer：

• PayerName具有和的属性/值对象PaymentMethod

Recipient和聚合都Payer被上下文边界完全分开。他们也有自己的存储库。

问题：

1. 使用同一个“数据库表”是否可以接受多个聚合（假设它们位于单独的有界上下文中）？

2. 在更多有界的上下文中可能需要客户数据。这不意味着每个有界上下文都有许多聚合、存储库和工厂实现吗？代码会有一定程度的冗余。这不会影响可维护性吗？

3. 跨聚合共享属性是否可以接受？一个例子是客户Name财产。这也意味着多余的验证码？

可用于在接收 BCcross-Bounded Context (BC) communication中创建的选项或任何最佳实践方法是什么？BC 在同一个 LAN 中，但在不同的服务器等上。理想情况下，每个 BC 中应该有一个端点，可以根据需要通过 DI 实例化正确的事件处理程序，而不是每个事件/事件处理程序有一个侦听器。Domain EventsDependency Injection (DI)Event Handlers

使用 DI 和本地事件处理程序，像这个简单的例子一样简单，只需很少的努力，但是一旦你在其他服务器上使用 http、tcp、消息队列等。它需要更多的努力和/或库来简化管道。

这适用于 C# .NET 环境。

领域驱动设计传递事件以分离限界上下文

MVC 中的用户操作应生成一个事件，该事件将传递给远程（同一 LAN）事件处理程序。

我测试过的：

1. MVC：触发并忘记服务调用（异步）->
2. （IIS 托管）收集数据并填充消息的 WCF ->
3. 通过 EasyNetQ/RabbitMQ ServiceBus 发送 ->
4. 该事件由处理事件及其数据的订阅者（使用从 WCF 服务端点初始化的 DI 容器）使用。

如果通过在 MVC 端循环来相当快地调用服务，我做了一些测试以了解它是如何工作的

MessageQueue 部分很快，基于它被发送到队列并在同一秒内被订阅者接收的时间戳。循环通过 WCF 服务调用非常慢。循环通过它们需要几秒钟。我尝试从 wsHttpBinding 切换到 netTcpBinding，并在 WCF 中使用 serviceThrottling。

WCF 不是强制性的，但似乎一个单独的事件处理项目（在发布者端）将是有益的，并且可以物理地位于 MVC 应用程序的其他位置（减少负载等）。WCF 是否适用于这种情况，或者我应该尝试使用 Windows 服务或其他一些自托管的控制台应用程序等，或者可能使用 MVC 中的线程来生成事件数据，还是有更好的场景？这种事件处理系统的最佳实践是什么？基本上，让某些东西生成事件数据似乎是有益的，因为它必须在某处进行处理，同时又不会减慢最终用户正在使用的 UI。

我是领域驱动设计的新手（我们有一个小伙子在推动我们使用它），我喜欢我所看到的。我了解洋葱架构，我相信它与 DDD 密切相关，但我不确定它如何与有界上下文一起工作。

在微软介绍中，我了解有界上下文的必要性

DDD 简介

但我不知道这些是不是单独的洋葱。似乎会有一些交叉，几乎就像里面有一个大洋葱和其他洋葱，这听起来很难实现。

洋葱架构第 1 部分

洋葱架构如何与有界上下文一起工作？

我已经开始将我的“超级”语境分解成更小的重点语境。在一个简单的场景中，我Student和LecturesPOCOS 和我EntityTypeConfiguration在一个名为StudentsAndLectures.

这些表是在我的 uber 上下文中定义的表关系网络的一部分。但是，我想以更有针对性的方式和有针对性的背景来管理学生和他们的讲座。

下面是我的 POCO 课程。

最后，我的实体类型映射器。

此外，My Focused context 包含仅适用于学生和讲座的 DbSet。

我的问题，如果我使用我的重点上下文查询如下特定学生，我的 .Lectures 导航属性返回空。但是，如果我使用创建数据库的完整（超级）上下文，我的导航属性会按照我的意愿延迟加载或急切加载。有谁知道为什么会这样？

经过进一步的测试和实验，我发现如果我包含一个DbSet存在于我的模型中的特定（非其他）附加组件及其相关ModelBuilder配置，那么一切正常。DbSet是一个实体， ，它是一个Registration具有导航属性的实体。另一个转折是，如果我保留实体的配置，但从我的重点上下文中删除，那么我的导航属性将停止再次添加。（该集合有 0 个元素）。StudentHasRequired (x => x.Student)ModelBuilderRegistrationDbSet<Registration>Lectures

我的困惑是，DbSet在我的重点上下文中添加一个如何影响我的导航属性为上述表/实体解析的方式？我该如何解决这个问题。任何帮助将不胜感激。

我正在尝试将域事件存储在 postgres 数据库中。很多事情我都不确定，也不想以后重新设计这个结构，所以我正在寻求有事件溯源经验的人的指导。我目前有下表：

我不确定：

1. 我应该存储领域事件的发起人吗？
   通过安全漏洞找到受损帐户可能会有所帮助，但我不知道要存储什么，例如通过 CRONjob。
2. 我应该以什么格式存储事件类型？
   我应该添加一个包含事件类型的表，还是类名就足够了？
   我应该添加事件组吗？
3. 我对有界上下文的定义感到困惑。据我所知，每个聚合都可以有多个有界上下文，因此我可以在多个模块中使用单个聚合的不同方面。听起来不错，因为例如帐户可以与许多事物相关，包括身份验证、授权、用户配置文件、用户帖子、用户合同等等……
   我不确定，域事件可以有多个有界上下文，还是只有一个，所以我也应该存储事件上下文吗？（对于我想重播与单个上下文相关的事件的情况）
   如何在单个聚合类中实现这么多属性，我应该使用某种组合吗？

我一直在阅读 Eric Evans 的 DDD：Tackling Complexity in the Heart of the Software 和上下文映射部分，Evans 引用了一个使用翻译器集成它们的 2 个有界上下文（预订上下文和网络遍历服务）的示例。

如果我理解正确，当我们创建模型时，我们将所有内容放入有界上下文中，为领域创建概念边界。我的问题是：

1. 如果一切都应该在有限的上下文中，那么翻译器应该位于哪里？在 Evans 的示例图中，翻译器位于两个有界上下文之外（介于两者之间）。

2. 假设我们有一个团队在开发 ERP。应该将 ERP 置于多个有界上下文中还是仅置于单个上下文中。基于 Evans 的示例，设计了有界上下文，以便多个团队可以在他们自己的模型上工作。但既然这是一个团队，他们难道不会从单一模型中受益，因此集成不会成为问题吗？还是我理解错了？

3. 在问题 2 的情况下，如果有多个有界上下文，如果在实现中，我们需要会计中的一个类在工资单中使用怎么办？我认为我们在这里不需要翻译，但我不确定如何分享所需的课程。只从另一个有界上下文中引用所需的类就可以了吗？

4. 最后，DDD 中的模块如何与有界上下文相关联？

我正在使用域驱动设计方法开发 Web 应用程序，但是我的应用程序的某些方面不适合 DDD。例如，我们需要批量更新员工工资。加载整个员工实体并为每个员工保存它是效率不高的，因为通常一次更新数百个薪水。此外，还需要同时执行其他任务，例如记录旧工资和记录新工资的生效日期。所以我会说这种类型的操作超出了我的核心域的有界上下文。此外，我了解，最好从程序的角度来处理此操作。这一切都很好

例如，我正在使用以下结构。

• 用户界面
• 应用
• 模型
• 基础设施

即使对于我的核心领域的有界上下文之外的事情，我也想坚持这种结构。我现在主要关心的是我的基础设施层。最初我在基础设施中使用以下内容：

• 存储库
• 查找器（用于单独的读取模型）
• 命令

我在 Finders 中放置了 ad-hoc 读取查询，在 Commands 中放置了 ad-hoc 命令。这样做的问题是某些操作需要一系列查询和命令，对我来说，将它们全部组合在一个单元中似乎更有条理。有点像存储库，但它不是提供对域实体的访问，而是封装了一组构成特定过程的查询和命令。

所以我正在寻找的是重新命名约定的建议，以将“命令”文件夹/命名空间更改为更好地描述一系列逻辑上适合的查询/命令。是否已经有我不知道的名称/模式？

更新：

我目前正在考虑使用命名空间“程序”来描述这些逻辑上组合在一起的查询/命令。一方面它是合适的，因为我所描述的类似于存储过程，并且描述性的是应用程序的这一部分使用的是过程而不是 DDD 方法。我唯一的疑虑是这种命名约定意味着使用存储过程，但事实并非如此。