Нет, как минимум объяснить надо. Желательно не просто на словах, а как-то обосновать, что поведение и навыки сотрудника не стыкуются с должностной инструкцией.
Лично я сходу не отличаю связанность от связности, особенно на слух. Поэтому использую термины каплинг и кахезия, чтобы было очевиднее и даже просто не оговориться.
Транзакции в распределенной системе слишком затратны, поэтому strong consistency заменяют на eventual. А если не использовать Outbox Pattern или подобный механизм – получают Optimistic Consistency (вместо стронг или евенчуал).
Непонятно насколько большая конкурентность за один айтем.
Есть подходы для высококонкурентных запросов, например билеты на матч в старт продаж.
Но если у вас не столь конкурентный паттерн, то я бы делал в том же ключе, что и oxidmod
Наверное, может, но есть сложность с транзакционными границами. Агрегат необходимо сохранять в транзакции целиком и обратно вычитывать тоже в транзакции*.
Приватный IsValid добавлен с целью показать, что агрегат может отказаться добавлять что-то в себя, если посчитает такой продукт невалидным для своего состояния, нарушающим его инвариант.
Нет, как минимум объяснить надо. Желательно не просто на словах, а как-то обосновать, что поведение и навыки сотрудника не стыкуются с должностной инструкцией.
Правда еще есть когезия, может этот термин форсить?)
Лично я сходу не отличаю связанность от связности, особенно на слух. Поэтому использую термины каплинг и кахезия, чтобы было очевиднее и даже просто не оговориться.
Транзакции в распределенной системе слишком затратны, поэтому strong consistency заменяют на eventual. А если не использовать Outbox Pattern или подобный механизм – получают Optimistic Consistency (вместо стронг или евенчуал).
Если у нас не хайлоад, то и за временем/порядком можно не так пристально следить, коллизии редки и легко разруливаются на уровне бизнес-логики.
Event Sourcing - отличный подход, на мой взгляд. Стоит ли его использовать прям везде – конечно, нет)
Вот пачка референсов https://github.com/heynickc/awesome-ddd#sample-projects
В общем случае домен != контекст != микросервис. Есть отличная статья на эту тему https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/
Самый большой и основной опыт я получил в Додо (не знаю как переложить на приложения), до этого те или иные паттерны тоже использовал.
В комментах голубым нельзя ¯\_(ツ)_/¯
Кощунственно выделять некликабельные тезисы и термины голубым)
Тот кто «знал», но оказался не столь везучим, не смог написать мемуаров.
Когда-то было так. Сейчас ближе к 15к. Ремни, улучшение дорожной сети и камеры все таки сделали свое дело
Есть подходы для высококонкурентных запросов, например билеты на матч в старт продаж.
Но если у вас не столь конкурентный паттерн, то я бы делал в том же ключе, что и oxidmod
Сложно сказать где оригинальный источник, но перевод уже был на Хабре https://m.habr.com/en/company/flant/blog/419733/ За пару лет немного поменялось, правда)
Поправил в примере на вариант
CanAddProduct.