使用DDD和CQRS处理域逻辑的重复

问题描述

我正在尝试使用DDD + CQRS，我无法理解如何处理这个域名逻辑重复问题：

I'm experimenting with DDD + CQRS and I can not understand how to handle this domain logic duplication problems:

首先，关于跨域重复：

情景1：
假设我有一些处理办公室员工的应用程序。我有3个有限的背景：程序员部门，质量保证部门和审计部门。每个BC都有自己的AR：程序员，测试者，工人。它们有99％的不同，每个逻辑不同，但每个都有Name，Surname和一个简单的方法getFullName，它们将这两个连接起来。

Scenario 1:Let's say I have some application which handles office employees. I have 3 bounded contexts: Programmer department, QA department and Audit Department. Each BC has it's own AR: "Programmer", "Tester", "Worker". They are 99% different, with different logic in each, however, each of those have "Name", "Surname" and a simple method "getFullName" which concatinates those two.

问题1：我如何（而且应该？）使常见的方法在每个AR中不重复？

Question 1: How do I (and should I?) make that the common method is not duplicated in each AR?

最简单的答案可能是使一些共享的人类课程，使这3个AR得到，但这反对DDD的想法，作为质量保障部门可能永远不需要getFullName方法，但需要一些其他共享方法。因此，这个解决方案将使域名被垃圾邮件使用未使用的方法。

Easiest answer is probably to make some shared "Human" class, and make those 3 ARs derive from it, but that is against the idea of DDD, as "QA Department" could never need the "getFullName" method but need some other "shared" method. Therefore this solution will make the domain spammed with unused methods.

现在关于CQRS代码重复：

Now about CQRS code duplication:

方案2：数据库包含发票。每张发票都有字段和和税。在显示发票页面中，我需要显示税款的发票总额。因此，在我的阅读模式中，我需要做总= + +税，以显示给最终用户。但是，用户可以按批准按钮，应该说，在其他数据库（会计或其他数据）中注册发票金额。所以，在我的写作模式中，我将再次需要做总= + +税。

Scenario 2: Database contains invoices. Each invoice has fields "sum" and "tax". In "show invoice" page I need to show invoice sum with tax. Therefore in my read model I will need to do "total = sum + tax" to show it to the end user. However, user can press "approve" button, which should, let's say, register the invoice sum in some other database (accounting or something). So, in my write model I will once again need to do "total = sum + tax".

问题2：我应该吗？）删除这种重复？

Question 2: How do I (and should I?) remove this kind of duplication?

当然，这是一个简单的场景，但在分析了我的一些现实生活中的应用程序后，我看到使用CQRS会在不同的地方需要大量的重复，因为许多地方的最终结果是从数据库中存储的数据计算出来的，而且在查询和命令操作上也是这样。

Sure, this is a simple scenario, but after analyzing some of my real life applications I see that using CQRS would require lots of heavy duplication in different places, as there are lots of places where the end result is calculated from the data stored in database, and that is done both on query and command operations.

任何想法？我错过了什么吗？

Any ideas? Am I missing something?

推荐答案

场景1

Scenario 1

1. 复制&将代码粘贴到三个有界的上下文中。


2. 为包含在共享库中的名称创建一个Value对象，其中包含了获取全名的逻辑。


3. 创建负责管理员工详细信息的员工有界环境。任何其他有界的上下文可以用于查找员工的详细信息。将发布活动以确保有界背景之间的一致性（例如 EmployeeJoinedCompanyEvent 包含其全名）。

1. Copy & paste the code into each of the three bounded contexts.
2. Create a Value Object for names contained within a shared library that encapsulates the logic of getting a full name.
3. Create an Employee bounded context responsible for managing employee details. Any additional bounded context can then use this for looking up an employee's details. Events would be published to ensure consistency between bounded contexts (e.g. EmployeeJoinedCompanyEvent containing their full name).

场景2

任何计算都应该是域模型的一部分。包含在实体，价值对象或域服务中。

Scenario 2

Any calculations should be part of your domain model. Contained within the Entities, Value Objects or Domain Services.

然后，在域中发布的事件中将包含任何计算结果（在本例中为总计）。可以从发布的事件中包含的值更新读取和写入数据存储。他们不应该自己做任何计算。

The result of any calculations - total in this example - are then included in the Events that are published from the domain. Both read and write data stores can be updated from the values contained within the published events. They should not be doing any calculation themselves.

例如，如果域发布一个 InvoiceApprovedEvent ，它将包含读取模型所需的所有数据。包括总税额和总金额。

As an example, if the domain publishes an InvoiceApprovedEvent it would contain all data necessary for the read model. Including the sum tax and total amounts.

事件也是有界上下文之间的主要整合手段。因此，如果您需要更新会计有界的上下文或外部系统，您将订阅从开票有界的上下文中的相关事件，并处理收到的事件。

Events are also the primary means of integration between bounded contexts. So if you need to update an Accounting bounded context or external system, you would subscribe to the relevant events from the Invoicing bounded context and handle the events as they are received.

我可以强烈建议实施DDD和CQRS的几个资源（假设您已经熟悉Eric Evan的DDD书）。

A couple of resources that I can highly recommend for implementing DDD and CQRS (assuming you're already familiar with Eric Evan's DDD book).

• Microsoft Patterns&实践 - （免费电子书）


• Vaughn Vernon（付费书）的

• Microsoft Patterns & Practices - Exploring CQRS and Event Sourcing (free eBook)
• Implementing Domain-Driven Design by Vaughn Vernon (paid book)

这篇关于使用DDD和CQRS处理域逻辑的重复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！