问题标签 [dddd]

我了解 REST + 事件溯源的基础知识。我从来没有在严格的 RESTful API 上工作过，也没有在任何事件溯源项目中工作过。

有人能解释一下两者是否可以一起使用吗？

与事件溯源一样，客户端发送事件，这是否意味着在服务器上只有一个事件集合，并且 API 的所有 POST 都将在该集合上，以便向其中添加事件？

客户端如何发现它可以发送到服务器的命令？

Although I've come across Kafka before, I just recently realized Kafka may perhaps be used as (the basis of) a CQRS, eventstore.

One of the main points that Kafka supports:

• Event capturing / storing, all HA of course.
• Pub / sub architecture
• Ability to replay the eventlog which allows the ability for new subscribers to register with the system after the fact.

Admittedly I'm not 100% versed into CQRS / Event sourcing but this seems pretty close to what an eventstore should be. Funny thing is: I really can't find that much about Kafka being used as an eventstore, so perhaps I am missing something.

So, anything missing from Kafka for it to be a good eventstore? Would it work? Using it production? Interested in insight, links, etc.

Basically the state of the system is saved based on the transactions/events the system has ever received, instead of just saving the current state / snapshot of the system which is what is usually done. (Think of it as a General Ledger in Accounting: all transactions ultimately add up to the final state) This allows all kinds of cool things, but just read up on the links provided.

我想知道如何正确建模我的聚合。域是会计，我有三个实体：Account、AccountingEntry（这应该是一个值对象吗？）和AccountingTransaction。该帐户可以说是客户的银行帐户。AccountingEntry 是帐户中的一个条目，AccountingTransaction 将构成单个事务的多个条目联系起来（例如，从帐户 A 转移到帐户 B）。一起。

我的想法是将 Account 和 AccountingTransaction 建模为聚合，AccountingEntry 建模为 AccountingTransaction 中的集合。这是为了允许会计交易汇总执行不变量，即交易中的所有条目必须总和为零。这些条目将包含对其关联帐户 ID 的引用（如果我们想撤销交易，这将很有用）。这些账户不会保存对条目的任何引用，但会保留余额。

我会使用 saga 来管理以交易方式记入和借记帐户的过程。

我想知道我是否正确地建模。

我还想知道如何确保无法创建包含对无效（不存在）帐户的引用（ID）的会计条目。该帐户是否应该用作创建条目的工厂，并传入它自己的 ID？

假设我有 X 作为聚合根，Y 作为另一个聚合根。使用 NoSql 文档数据库，X 通过 Y 的 Id 保存对 Y 的引用。如果 Y 被删除（独立于 X 的上下文之外），则 X 持有对不存在的 Y 的引用。

在 DDD 中消除或解决此问题的建议解决方案是什么？

正如 DDD 从业者建议的那样，业务规则的验证必须在域对象（实体、值对象和域服务）内实现，并且在我读过的某个地方也遵循它们自己的上下文，我们应该进行技术验证（例如检查长度、正确的输入格式、正确的数据类型，...）在域模型之外和应用层之类的地方，以保持域对象清晰。

现在 我的问题是：

如果我们有信用卡号的值对象，我们是否仍应将技术验证排除在值对象之外？换句话说，当我们处理值对象时，“自我验证”一词不涉及技术验证？

当不正确的借记卡号码甚至电子邮件地址有可能破坏业务规则时，该怎么办？

为了更清楚，请注意这个代表借记卡号的值对象：

根据此代码，有一种验证方法可以执行算法来确定卡号的格式是否正确？您认为这是进行此类验证的正确位置吗？

我正在尝试使用 dddd 实现事件源系统。目前，我正在为我的事件如何以及在何处跨越有界上下文的边界而苦苦挣扎。

想象有两个有界上下文：

1. 产品管理
2. 物流系统

产品管理拥有关于产品的所有知识。为简单起见，它只是“名称”。物流系统也有产品，但对它们的元数据一无所知。对他们来说，它主要是一个带有 ID 的物理盒子。但是当有人扫描这个产品时，他们也想显示名称。因此，ProductManagement BC 应该通知 Logistics BC，产品已注册并且名称已更改。因此，我将以 ProductManagement 中的事件结束，这些事件是从 ProductAggregate 内部引发的：

当我正确理解这些是我将保存到事件存储中的事件。这些也是将发布到消息总线中的事件。所以在物流方面，我会订阅这些活动。到目前为止，一切都很好。

现在的问题是：我将如何在物流方面处理这个事件？Vaughn Vernon 在一次演讲中说，最好的做法是在应用层有一个事件处理程序，所以它基本上是一个应用程序服务。他还说，最好将其转换为一个或几个命令。我是否再次将所有收到的事件保存在物流端？我还要保存命令吗？如果出现问题，如何重现当前状态？或者我怎么知道，这不是接收限界上下文中处理的错误，而是错误的事件。如果我的转换命令被拒绝，我该怎么办？

我知道物流方面的总量没有计算或变化。但我认为这对我的问题并不重要。

我知道 DDD 非常适合基于任务的 UI，但我正在重构一个遗留应用程序，其中我有贫血域模型（许多设置器没有业务逻辑）。

第一步是让它到达模型并添加领域事件。虽然添加用于创建（TaskCreated在构造函数中）和删除（TaskRemoved）模型的事件是一个简单的过程，但我正在努力更新模型。

我们有一个带有 PUT/tasks/{id}端点的 RESTful API。在底层，框架将响应的主体映射到 DTO 对象，然后一一调用 setter：

我想在任务更新时收听一些事件，并在例如谷歌日历中更新它。正如您所想象的那样，如果我在每个setter（TextChanged、StartDateChanged）中记录事件并监听所有事件，我最终会收到许多对 Google API 的 API 调用，这不是我想要的。

问题是：我应该如何以正确的方式使用更新操作？我应该setters用一个update(newData)电话替换所有这些电话并在那里只调度一个域事件吗？更新任务后如何只对谷歌日历进行一次API 调用？

这个问题是相关的，但比这个问题更具体。

我将在这里使用一个简单的例子。假设我们User在一个上下文中有一个Customer实体，在另一个上下文中有一个实体。这是同一实体的两种不同表示。

假设User和Customer都有一个电子邮件地址，但电子邮件地址总是通过User所属的有界上下文更改。因此，用户上下文是电子邮件地址的真实来源。所以理想情况下，我希望上下文中的电子邮件地址从客户上下文的角度来看Customer是不可变的。

因此，当在用户上下文中更改电子邮件地址时，EmailAddressChanged会发出一个事件。这可以; 我订阅了Customer上下文中的事件。但是，我现在需要通过更改Customer电子邮件地址来处理此事件。所以我需要某种命令方法来进行这种改变。

User除了从上下文处理事件时，如何确保不使用命令方法？

如果我在两种情况下都允许突变，那么它们都会成为事实的来源，我需要将事件和处理程序的数量增加一倍，以确保信息在两种情况下保持一致

我正在开发微服务，我正在使用带有 CQRS 模式的事件溯源，在我的情况下，如果用户从一项服务中删除/更新，我希望它发布事件和其他服务来订阅它并删除有关该用户的条目也来自它的数据库。

我想问一下如何在事件溯源中使用 pub/sub 模式，哪个事件存储可以用于它，因为目前我看到有些人使用 Azure Tables，但它如何用作 pub/sub？

我已经阅读了双调度模式，它可以将服务接口传递给聚合方法：https ://lostechies.com/jimmybogard/2010/03/30/strengthening-your-domain-the-double-dispatch-pattern/ , http://blog.jonathanoliver.com/dddd-double-dispatch/。

在我的域中，我有一个BitbucketIntegration聚合，它是远程 bitbucket 帐户的本地副本，其中 包含一些额外的域特定数据。现在，我必须从云同步存储库和团队等，以便能够在它们上进行业务操作。在我的第一个实现中，我使用服务访问 Bitbucket Cloud，然后设置聚合的存储库、团队、帐户。通过这种方式，我将DDD与Anemic Domain Model混合在一起，因为一半的聚合状态是使用服务中的类似 setter 的方法设置的。使用Double Dispatch，我可以通过例如BitbucketService接口到方法参数。这样，聚合可以更多地保护它的不变量，因为某些数据只能通过连接到其余服务来验证（例如，如果聚合的accessToken,bitbucketAccount和repositories同步），这是服务的责任。还有一件事是accessToken我的聚合中有一个字段，这只是一个技术问题。

是否有任何推荐的模式将远程资源的副本保存在 ddd 聚合中？另外，如何避免技术方面的影响？还是第一种使用域服务的方法足够好？

现在代码看起来像：

作为旁注，我只查询Bitbucket。

编辑： Martin Fowler 写了关于访问外部系统的文章，包括定义反腐败层，它将远程资源表示转换为域类型。