Модуль 6. Repository

Да, может, если они участвуют в одной бизнес-транзакции и должны измениться согласованно. Но не злоупотребляйте этим, если возможно реализовать отложенную согласованность (eventual consistency), то она всё же предпочтительнее.

Ниже мнения известных экспертов DDD.

Ниже комментарий Владимира Хорикова, по этому вопросу. Владимир Хориков посвятил много лет изучению DDD, написал несколько книг.

Sometimes it is actually good practice to modify multiple aggregates within a transaction. But it’s
important to understand why the guidelines exist in the first place so that you can be aware of the
consequences of ignoring them.

When the cost of eventual consistency is too high, it’s acceptable to consider modifying two objects
in the same transaction. Exceptional circumstances will usually be when the business tells you that
the customer experience will be too unsatisfactory. You shouldn’t just accept the business’s decision, 

though; it never wants to accept eventual consistency. You should elaborate on the scalability,
performance, and other costs involved when not using eventual consistency so that the business can
make an informed, customer‐focused decision.

Another time it’s acceptable to avoid eventual consistency is when the complexity is too
great. You will see later in this chapter that robust eventually consistent implementations
often utilize asynchronous, out‐of‐process workflows that add more complexity and
dependencies.

To summarize, saving one aggregate per transaction is the default approach. But you should
collaborate with the business, assess the technical complexity of each use case, and consciously ignore
the guideline if there is a worthwhile advantage, such as a better user experience.

Try not to confuse this guideline with loading or creating aggregates. It
is perfectly fine to load multiple aggregates inside the same transaction as long as
you save only one of them. Equally, it is permissible to create multiple aggregates
inside a single transaction because adding new aggregates should not cause
concurrency issues.

Nick Tune "Patterns, Principles, and Practices of Domain-Driven Design" 

Consider an additional factor that could further support diverting from the rule: user-aggregate affinity. Are the business work flows such that only one user would be focused on one set of aggregate instances at any given time? Ensuring user-aggregate affinity makes the decision to alter multiple aggregate instances in a single transaction more sound since it tends to prevent the violation of invariants and transactional collisions.

Effective Aggregate Design, Part 2, by Vaughn Vernon, licensed under CC BY-ND 3.0 DEED, Copyright © 2011 Vaughn Vernon.

При работе с этой ситуацией мы должны либо рассмотреть возможность использования согласованности в конечном итоге, либо мы можем воспользоваться подходом, который Вон Вернон охарактеризовал как «user-aggregate affinity». 

Последний случай особенно распространен, когда наш дизайн следует парадигме чистой архитектуры (управляемой вариантом использования). Варианты использования могут изменять два или более агрегатов в одной транзакции посредством последовательности синхронных вызовов методов агрегатов с последующими вызовами репозиториев для сохранения измененного состояния. 

Принятие за границу согласованности варианта использования значительно упрощает рассуждения и реализацию бизнес-инвариантов, охватывающих несколько агрегатов.

В приложениях нередко используется паттерн репозиторий для инкапсулирования логики работы с источниками данных. И нередко мы оперируем множеством сущностей и моделей, для управления которыми создаётся также множество классов-репозиториев. Паттерн Unit of Work позволяет упростить работу с различными репозиториями и даёт уверенность, что все репозитории будут использовать один и тот же контекст данных.