规则“每笔总计一笔交易"是否应适用?建模领域时要考虑到什么? [英] Should the rule "one transaction per aggregate" be taken into consideration when modeling the domain?

问题描述

考虑域事件模式和此帖子，为什么人们建议每个交易模型都保持一个汇总?在许多情况下，一种聚合可以改变另一种聚合的状态.即使删除集合(或更改其身份)也将导致更改引用该集合的其他集合的状态.有人说，每个聚合保持一个事务有助于扩展性(每个服务器保持一个聚合).但是这种思维方式是否打破了DDD的基本特征:技术不可知论?

Taking into consideration the domain events pattern and this post , why do people recomend keeping one aggregate per transaction model ? There are good cases when one aggregate could change the state of another one . Even by removing an aggregate (or altering it's identity) will lead to altering the state of other aggregates that reference it. Some people say that keeping one transaction per aggregates help scalability (keeping one aggregate per server) . But doesn't this type of thinking break the fundamental characteristic about DDD : technology agnostic ?

因此，根据上述陈述和您的经验，设计汇总，领域事件是否会导致其他汇总发生变化，这很不好，并且这将导致每个交易包含2个或更多的汇总(例如:订单中放置了100件商品，将客户的状态从正常更改为VIP)?

So based on the statements above and on your experience, is it bad to design aggregates, domain events, that lead to changes in other aggregates and this will lead to having 2 or more aggregates per transaction (ex. : when a new order is placed with 100 items change the customer's state from normal to V.I.P. )?

推荐答案

聚合将相关的业务对象分组，而聚合 root (AR)是该聚合的代表". AR本身是一个建模(更大，更复杂)域概念的实体.在DDD中，模型始终是相对于上下文(有界上下文-BC)而言的，即该模型仅在该BC中有效.

An aggregate groups related business objects while an aggregate root (AR) is the 'representative' of that aggregate. Th AR itself is an entity modeling a (bigger, more complex) domain concept. In DDD a model is always relative to a context (the bounded context - BC) i.e that model is valid only in that BC.

这使您可以定义代表特定业务环境的模型，而无需仅将所有内容推到一个模型中. 订单在一个上下文中是一个AR，而在另一个上下文中则只是一个ID.

This allows you to define a model representative of the specific business context and you don't need to shove everything in one model only. An Order is an AR in one context, while in another is just an id.

由于AR几乎封装了所有较低层的概念和业务规则，因此它作为一个整体(即事务/工作单元)起作用.存储库始终与AR配合使用，因为1)存储库始终处理业务对象，并且2)AR代表给定上下文中的业务对象.

Since an AR pretty much encapsulates all the lower concepts and business rules, it acts as a whole i.e as a transaction/unit of work. A repository always works with AR because 1) a repo always deals with business objects and 2) the AR represents the business object for a given context.

当您的用例涉及两个或多个AR时，业务工作流程和该用例的正确建模至关重要.在很多情况下，这些AR可以独立修改(一个人不关心其他)，或者AR作为其他AR行为的 result 的 result 而更改.

When you have a use case involving 2 or more AR the business workflow and the correct modelling of that use case is paramount. In a lot of cases those AR can be modified independently (one doesn't care about other) or an AR changes as a result of other AR behaviour.

在您的示例中，这很简单:当客户下达100件商品的订单时，会生成并发布域事件.然后，您将拥有一个处理程序，该处理程序将检查该订单是否符合客户促销规则，如果符合，则会发出命令，该命令的结果是将客户状态更改为VIP.

In your example, it's pretty trivial: when the customer places an order for 100 items, a domain event is generated and published. Then you have a handler which will check if the order complies with the customer promotions rules and if it does, a command is issued which will have the result of changing the client state to VIP.

域事件非常强大，可以在最终一致环境中实现事务.旧的db事务是一个实现细节，通常在持久化一个AR时使用(记住AR被视为一个逻辑单元，但是持久化一个事务可能涉及多个表，因此是db事务).

Domain events are very powerful and allows you to implement transactions but in an eventual consistent environment. The old db transaction is an implementation detail and it's usually used when persisting one AR (remember AR are treated as a logical unit but persisting one may involve multiple tables hence db transaction).

最终一致性是领域事件的特征"，它自然适合于一个丰富的领域(实际上是现实世界).在某些情况下，您可能需要即时的一致性，但是这是特殊的情况，它们与UI有关，而不是Domain的工作方式.当然，它确实取决于一个域到另一个域.在您的示例中，客户不介意在下订单2秒或2分钟后成为VIP，而不是同一个毫秒.

Eventual consistency is a 'feature' of domain events which fits naturally a rich domain (and the real world actually). For some cases you might need instant consistency however those are particular cases and they are related to UI rather than how Domain works. Of course, it really depends from one domain to another. In your example, the customer won't mind it became a VIP 2 seconds or 2 minutes after the order was placed instead of the same milisecond.

这篇关于规则“每笔总计一笔交易"是否应适用?建模领域时要考虑到什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！