问题标签 [bounded-contexts]

我了解如何使用部分视图，并且了解 Ajax.ActionLink 和 Ajax.BeginForm 如何在视图中设置它们。我假设每个局部视图都有自己的控制器。我在这里考虑有界上下文，因为在每个局部视图中都可以通过自己的控制器与自己的有界上下文对话

我想我缺少的部分是：

1. 如何将部分视图包含在“主视图”（或持有视图）中，并让这些部分视图中的每一个独立发布到单独的控制器操作，然后返回以刷新部分视图而不加载“主视图”或持有视图.
2. “主”视图或持有视图仍然需要有自己的控制器，我想阻止主控制器重新加载其视图，并让主控制器的操作方法生成的视图持有对这两个部分的引用意见。

我似乎可以采取两种方法，一种是使用“Ajax”。MVC3 的功能，另一个是直接使用 jQuery 并从客户端手动处理所有这些交互。

我正在尝试做的事情是两种方式，还是一种方式“更适合”这种类型的复合 ui 构造？

到目前为止，我所看到的只是复合 ui 构造的简单示例，例如通过 Ajax.ActionLink 刷新页面上的单个链接的链接，或者编写为 Ajax.BeginForm 的表单，该表单使用来自部分观点。

假设我为我的客户建立了一个系统，允许赌徒维护一个赌注组合并随着时间的推移跟踪他们的收益/损失。该系统支持许多复杂的领域逻辑 - 投注不同的运动，将胜利滚动到其他投注等。

接下来，我的客户想要支持提示者的想法。提示者实际上并不赌博，而是创建“提示表”，这是他们关于下注的提示。提示表可以有不同的种类——有些可以包括任何可投注赛事的提示，其他的只提供赛马提示，等等。我的客户希望系统以与跟踪赌徒表现相同的方式跟踪推销员的表现，并且能够比较不同类型的推销员内部和之间的表现（例如，谁是最好的赛马推销员？他们通常比足球提示者表现更好吗？）

现在，赌徒和推销员之间的领域语言完全不同，并且还有赌徒投资组合不存在的小费表的额外分类。这表明这些是单独的有界上下文。但是，有很多共享逻辑，因为它们都随着时间的推移跟踪性能。

所以我的问题是：

1. 这些真的是独立的有界上下文吗？我对在赌徒上下文中添加分类持谨慎态度（感觉就像一个滑坡）。
2. 如果它们是不同的上下文，我应该：
   • 在它们之间共享性能跟踪逻辑（即共享 DLL、jar 等）？这在感觉错误的上下文之间创建了紧密的实现耦合。
   • 将性能跟踪逻辑留在赌博有界上下文中，将分类逻辑放在提示者边界上下文中，并让它要求赌博上下文跟踪性能？在这种情况下，提示者上下文似乎会将命令发送到赌博上下文，这再次让人感觉不对（我对事件更满意）。
   • 做其他事情......某种在两个上下文之间进行通信和关联的组合层？

澄清

赌徒的投资组合和提示者的提示表几乎相同 - 唯一的区别是提示表可以分类（例如赛马、足球等）。

绩效跟踪是关于衡量投资组合/提示表的损益。

我正在使用 DDD 原则制作应用程序。在尽可能多地考虑了所有事情之后，我开始制作我的限界上下文。我还没有设置最终结构，但到目前为止，我的应用程序将包含以下有界上下文：

1. 员工管理
2. 购买
3. 档案
4. 报告

我希望它尽可能地可插拔，因此我可以例如单独开发和维护它们。他们可能会公开 WCF 或 Web API 以与他们交互。

我将使用Udi Dahans 实现一个简单的 CQRS 模式。我不想一直使用事件溯源、消息总线等，因为这不会是一个高度协作的应用程序（少于 1000 个用户，而且他们不太可能编辑相同的小数据集），这将增加了很多不必要的复杂性。

所以对于问题：

员工和部门实体对所有 BC 都是通用的，如何对其建模？

部门是组织结构的一部分，因此在员工管理 BC 中，员工在一个部门工作，他们可以管理一个部门，并且他们有他们工作过的部门的历史。

在采购 BC 中，商品从一个部门采购，然后交付给一个部门。供应商与不同部门有不同的合同。

在存档中，一些信息将被存档并绑定到一个部门，等等。

这几乎同样适用于员工。

如何持久化有界上下文中的数据？

它们可以映射到同一个数据库或每个都有自己的数据库。

到目前为止我的一些想法

如何建模
我应该再制作一个名为“公司”或“组织”的 BC 并在那里管理部门吗？

根据上面提到的 Udi Dahans 文章，我应该为每个 BC 创建一个部门实体和一个员工实体，其中包含我需要的 BC 字段和行为。这听起来很合理，但是我正在考虑如何实际使用它，但我无法弄清楚。我需要访问在其他地方管理的部门，但我究竟该怎么做而不是混合我的 BC？

如何使用？
假设我通过查询从某个地方获取了我的部门列表。在 UI 中，我得到了我也想购买的部门列表。这是该部门的第一次采购，因此采购部 BC 尚不知道该部门……因此采购部对象中的采购部对象将填充从另一个 BC 维护的数据 - 那么我该如何坚持呢？如果不存在，我需要添加一些信息，例如送货地址和发票地址？

在“注册部门 UI”中，我是否应该在所有 BC 上调用“RegisterDepartment”服务，然后确保这些与通过 UI（MVC 控制器）所做的所有更改同步？

对员工也是如此。我想知道哪个员工进行了购买或将某些东西放入档案中。因此，不知何故，我也需要这些 BC 中的员工对象，但从不同的 BC 管理它们。

持久
化 上面的一些挑战可以通过将不同的员工对象映射到数据库中的同一个表来解决。Purchasing BC 和 Archive BC 不能注册新员工，但会将信息附加到那里的员工，并将他们与同一数据库中的其他对象联系起来。然后数据库将确保所有 BC 仍然生活在同一个世界中......

我需要建议，所以我最终不会做出以后很难维护的东西。

在我当前的项目（电子商务网站）中，我们有不同的限界上下文，例如：结算过程中的计费、交付或付款。

最重要的是，根据客户将购买什么，结帐过程会有所不同。因此，根据她购物车的内容，结帐过程中的步骤数可能会有所不同，否则我们不会/不会询问她某些信息。

那么是否应该为每种不同类型的结帐流程创建不同的有界上下文？

例如，Order 聚合根将根据结帐流程而有所不同 EticketsOrder（在这种情况下，我们不需要送货地址，因此我们不会向用户询问） Ticket BillingAddress

ClothesOrder （在这种情况下，我们需要一个送货地址，并且在结帐过程中将有一个额外的步骤来获得这个） Clothes BillingAddress DeliveryAddress

这种分离将意味着创建两个不同的域实体，即使它们具有相似的属性。

模拟此类问题的最佳方法是什么？如何找到上下文边界？

我有一个使用通用上下文的 UnitOfWork。如何让存储库决定使用结构映射的具体上下文？

谢谢，

道格

我们尝试在我们的项目中遵循 SOA 和 DDD 原则。我们使用 NServicebus 作为消息总线。到目前为止，我们有 20 多项服务。

你们如何设置监控（我不是在谈论技术监控——比如服务“xyz”是否可达——硬盘是否已满）？

例如

如果下订单并在 5 天后完成发货，但它应该在 1 天后执行......这是一个错误情况。

或者另一个例子：运输完成。现在我们向客户发送电子发票。我们必须存档该发票并与第三方（存档提供商）异步交谈以检索我们的发票。如果 5 天后仍未检索到该发票……那就是错误情况。

在定义如何对错误的标准和放置这些标准的位置进行建模时，我遇到了问题。

在哪里 ...

...您是否设置了监控规则？

监控规则是您的有限上下文的一部分吗？我想是的。
监控规则是否与实体直接相关？我想不是。
监控规则是否与聚合直接相关？我想不是。

监控规则就像跨多个聚合的域服务，但与域服务相反，它也可以跨多个有界上下文。

谁负责？

如何 ...

...您是否在代码中设置了监控规则？

如果你想把它做对，它真的需要付出很大的努力。否则，您可以非常便宜地做到这一点（在这里和那里进行一些查询），但那是针对 SOA 的（我关心的主要部分）

请指导我找到一个清晰且易于实施的解决方案。

我也很高兴了解您如何设置它。

Question context

So I organized my application into bounded contexts (Eric Evans' "domain-driven design"). One of the bounded contexts is the "gameplay context." It, for instance, contains an interface Gamer

There is also an implementation that is able to persist a Gamer's state to a database.

Far, far away, inside another bounded context called "accounts context," I have classes and interfaces that deal with the users of my application. For instance, there is an interface called Account.

So a user / Account can be signed up or not. For any Account, there exists a corresponding Gamer.

Challenge

I have a business rule: Never persist sensitive data anyhow related to a non-signed-up Account.

For example, this means that some non-signed-up Account's JpaGamer instance cannot write data to the someSensitiveData field. You could informally say that this JpaGamer is a "non-signed-up JpaGamer".

I don't want to hardcode any accounts-related logic into anything gameplay-related (and the same the other way around).

How can I implement such business rules in Java without tainting either bounded context with concepts from the other bounded context?

To fulfill the business rule, I have the idea that whenever there is a "non-signed-up JpaGamer", I wrap that JpaGamer inside a SparsePersistingGamer. The SparsePersistingJpaGamer would simply not forward to the underlying JpaGamer any method that could potentially tamper with someSensitiveData.
But now I have a problem with the someGamer.getFriends() method. For the SparsePersistingGamer, it would lazily load all that gamer's friends from JPA, returning a set of plain JpaGamers that are not aware of the (and any other) business rule, therefore persisting someSensitiveData for potentially "non-signed-up JpaGamers".

Which strategies do you apply to tackle similar and related situations?

由于在我的应用程序中对“有界上下文”（Eric Evan 的域驱动设计）进行了重大重构和重新架构，一些有界上下文的已发布接口及其方法在命名和语义上发生了变化（此处的已发布接口意味着该接口是从另一个有界上下文）。

我现在正在实现这个更新的有界上下文，我必须决定我更改的接口的包命名。

• 我应该保留旧名称吗？my.company.old.package.name
• 我应该添加版本号吗？my.company.old.package.name.2
• ?

在我的具体情况下，由于更新的限界上下文仅在我自己的应用程序中使用，并且所有其他客户端限界上下文很少，因此也可以更改这些客户端限界上下文以适应任何新的名称和语义。

通常，可能有一些标准/指标/经验法则/最佳实践可以帮助我决定包名称。你的是什么？

我已经为我们全新的 Intranet 项目创建了一个基础架构，并尝试遵循几乎所有的最佳实践。我还想提一下，这是我第一次从零开始创建架构。

目前我的基础设施的第一个版本已经准备好并且运行良好。但我想在下一个版本中实现有界上下文结构。

我试图在下面解释当前的情况。

DbCore：负责数据操作。Entity Framework 5 代码首次使用。只有一个 DbContext 类和其中定义的所有 DbSet。GenericRepository 模式和 Unit of Work 模式也是基于以下接口实现的。

IGenericRepository

工作单位

Models：负责存储 DbCore 和 Entity Framework Domain 的实体模型：表示业务逻辑层还存储存储在 Models 项目中的实体对象的 DTO。当前业务逻辑存储在实现以下接口IService的 Service 类中

该服务类通过 ctor 参数获取 UnitOfWork 并用于操作。Automapper 还实现了将实体对象转换为 DTO，反之亦然。从现在开始，所有上层不再对实体模型感兴趣，只使用 DTO。所以几乎所有的项目（包括 api 和 web ）都引用了这个项目。

Common：负责存储常用的库，如日志记录。

WebCore：负责存储 API 或 MVC 等基于 Web 的项目的常用库。还包含基于 MVC 的项目的扩展、处理程序和过滤器。

Api： ASP.Net MVC Web API 项目代表服务层。使用域层并服务于客户端。控制器获取 IService 接口作为 ctor 参数，并使用它通过域层访问数据层。

Web：基于 ASP.Net MVC 4 的 Web 项目，负责与用户交互。使用 Api 方法来访问数据。所有控制器都有一个名为 IConsumeRepository 的接口，它通过 HttpClient 连接 API。

Autofac 负责所有项目的 IoC 和 DI。

现在这是我当前的基础设施，我想我解释了需要评估的所有内容。

现在我试图弄清楚以下事情，

问题1：有什么不能像我使用的那样被执行吗？

问题 2：实现限界上下文的最佳方法是什么？我最近观看了 Julie Lerman 的视频并查看了许多示例项目。我看到从 DbContext 派生 BC 的常见事情。但我不能确定。因为我认为 BC 应该在域（业务逻辑）层而不是 DbCore（数据访问）层。

问题 3：正如我上面提到的，我的 Api 和 Web 项目使用 DTO，因此它们都需要引用域层。但我不喜欢它，因为我使用 API 将业务层与 UI 分开，并为实体再次耦合它们。但我找不到比这更好的方法了。

这是一个很长的问题，但如果您与我分享您的想法以创建更好的架构，我将非常高兴。

我有一个相当大的数据库，大约 80 个表左右。因此，我决定将表分隔为有界上下文，而不是将所有 80 个表放在 1 个大 edmx 文件中。

所以我有有限的上下文，比如销售、客户等。

我的客户 edmx 文件中有我的主要客户表。但是，我还需要从销售 edmx 上下文的客户表中访问某些字段，而不是全部，而是 1 或 2 个字段（例如，我只需要客户名称，而不是整个客户对象/表）。

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