Непонятно насколько большая конкурентность за один айтем.
Есть подходы для высококонкурентных запросов, например билеты на матч в старт продаж.
Но если у вас не столь конкурентный паттерн, то я бы делал в том же ключе, что и oxidmod
Наверное, может, но есть сложность с транзакционными границами. Агрегат необходимо сохранять в транзакции целиком и обратно вычитывать тоже в транзакции*.
Приватный IsValid добавлен с целью показать, что агрегат может отказаться добавлять что-то в себя, если посчитает такой продукт невалидным для своего состояния, нарушающим его инвариант.
Конечно может. Во-первых, обойдемся без деления на админскую часть и клиентскую. Есть доменная сущность и операции с ней. Делить по пользовательскому интерфейсу — плохая задумка. Если вы хотите разделить эти агрегаты, то скорее всего придется разделить и хранение. И перейти к eventual consistency.
Второе, ОрдерРекорд — не анемичная модель. Это по сути readonly модель без логики и сеттеров.
Если хочется переиспользовать и операции прям одинаковые, и сторадж используется тот же самый, то для грида вытаскиваем только ссылки и номера заказов. Можно и больше данных (сумма, например) для чтения. Это нарушение чистоты для перформанса. А уже при открытии конкретного заказа загружаем наш агрегат.
Типичное Разделяй и властвуй. Когда у вас контекст ограничен, команда может сосредоточено пилить этот контекст. Не надо держать в голове 100500 связей с остальными контекстами.
Чем больше продукт и команда, тем сложнее процессы, независимо от того используется ли DDD или исключительно BBoM. Но DDD позволяет управлять возрастающей сложностью.
Про базу.
В идеале наша модель чиста и не зависит от внешних вызовов. Но не всегда это так и агрегат может использовать внешние сервисы для похода в базу и подобного.
В общем случае домен != контекст != микросервис. Есть отличная статья на эту тему https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/
Самый большой и основной опыт я получил в Додо (не знаю как переложить на приложения), до этого те или иные паттерны тоже использовал.
В комментах голубым нельзя ¯\_(ツ)_/¯
Кощунственно выделять некликабельные тезисы и термины голубым)
Тот кто «знал», но оказался не столь везучим, не смог написать мемуаров.
Когда-то было так. Сейчас ближе к 15к. Ремни, улучшение дорожной сети и камеры все таки сделали свое дело
Есть подходы для высококонкурентных запросов, например билеты на матч в старт продаж.
Но если у вас не столь конкурентный паттерн, то я бы делал в том же ключе, что и oxidmod
Сложно сказать где оригинальный источник, но перевод уже был на Хабре https://m.habr.com/en/company/flant/blog/419733/ За пару лет немного поменялось, правда)
Поправил в примере на вариант
CanAddProduct.Это если вы хотите построить универсальную модель. В статье я отговариваю от этого и считаю анти-паттерном.
Ну а все дальнейшие размышления идут насчет того как скрестить DDD и универсальную модель.
В идеале никак, но есть большая часть DDD про contexts map – там все расписывается, в том числе и shared kernel.
Второе, ОрдерРекорд — не анемичная модель. Это по сути readonly модель без логики и сеттеров.
В идеале наша модель чиста и не зависит от внешних вызовов. Но не всегда это так и агрегат может использовать внешние сервисы для похода в базу и подобного.