Пройденные паттерны:

Domain model

Subdomain - к примеру суть бизнеса Netflix — развлечения. Но для достижения своих целей компания должна работать в нескольких Subdomain, вместе они составляют бизнес-сферу компании. Например, Netflix должен управлять контентом, покупать лицензии места, управлять созданием собственного контента и управлять платежами и т.п. Нам необходимо развивать все эти предметные области бизнеса, чтобы добиться успеха в основной нашей сфере бизнеса, а именно в сфере развлечений. https://martinfowler.com/eaaCatalog/domainModel.html

Bounded Context - это граница доменной модели, которая представляет концепции предметной области, сущности, их отношения и их правила. Одна и та же доменная область может быть представлена бесконечным числом вариантов Bounded Context. https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c

Aggregate - это кластер объектов предметной области, которые можно рассматривать как единое целое. Примером может быть заказ и его позиции, это будут отдельные объекты, но полезно рассматривать заказ (вместе с его позициями) как единый агрегат. Агрегат будет иметь один из своих объектов-компонентов, являющийся корнем агрегата. Любые ссылки из-за пределов агрегата должны направляться только в корень агрегата. Таким образом, корень может обеспечить целостность агрегата в целом. https://medium.com/ingeniouslysimple/aggregates-in-domain-driven-design-5aab3ef9901d

Value Object (объект значения ) - представляет собой элемент или понятие вашей предметной области, которое известно только по своим характеристикам; Value Object используются в качестве дескрипторов для элементов вашей модели; Value Object не требуют уникальной идентичности. Поскольку объекты типа Value Object не имеют концептуальной идентичности в модели, идентичность определяется их атрибутами. Объекты типа Value Object не нуждаются в выделенном идентификаторе, поскольку они всегда связаны с другим объектом и, следовательно, понимаются в определенном контексте. Например, у вас может быть сущность заказа, которая использует Value Object для представления адреса доставки заказа,  информации о периоде доставки и т. д. Ни одна из этих характеристик не нуждается в идентичности как таковой, потому что она имеет значение только в контексте принадлежности к заказу. Адрес заказа, не прикрепленный к заказу, не имеет смысла. Хорошим примером Value Object являются деньги. Вас не волнует идентичность купюры, вас волнует только ее номинал(1,2,3,100) и вид валюты (рубль, доллар, евро). Если бы кто-то обменял пятидолларовую купюру на ту, что есть у вас в кошельке, это не изменит того факта, что у вас все еще есть пять долларов. Конечно, в реальной жизни деньги могут иметь уникальный идентификатор в виде порядкового номера, но модель предметной области не отражает реальной жизни. Вместо этого это его абстракция, созданная для удовлетворения потребностей вариантов использования в проблемной области. https://enterprisecraftsmanship.com/posts/value-objects-explained/

Entity (сущность) - представляет концепцию в вашей области, которая определяется ее идентичностью, а не ее атрибутами. Хотя идентичность объекта остается неизменной на протяжении всего его жизненного цикла, его атрибуты могут изменяться. Entity отвечает за определение того, что значит быть одинаковым; в коде это часто достигается переопределением операций равенства класса. Примером entity является продукт; его уникальный идентификатор не изменится после того, как он будет установлен, но его описание, цена и т. д. могут быть изменены много раз. Entity изменяемы, поскольку атрибуты могут изменяться. https://enterprisecraftsmanship.com/posts/entity-base-class/

Domain Event - События предметной области означают, что что-то произошло в предметной области, которая волнует бизнес. Вы можете использовать события как форму связи между агрегатами. Часто операция над одним агрегатом может привести к побочным эффектам, выходящим за границы агрегата. Другие агрегаты в модели могут прослушивать события и действовать в соотвествии со своей бизнес логикой. https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c

Инварианты — это правила, обеспечивающие согласованность модели предметной области. Всякий раз, когда происходит изменение объекта или агрегата, бизнес-правила по-прежнему применяются. Примером инварианта является правило, утверждающее, что клиент всегда должен иметь полный адрес. Чтобы убедиться, что вы придерживаетесь этого инварианта, не давайте пользователю возможность самостоятельно редактировать строки адреса, что делает его недействительным. Вместо этого рассматривайте адрес, возможно, как объект значение, чтобы гарантировать, что изменение приведет к тому, что инвариант останется действительным.


Статьи по теме:
Основные концепции DDD https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/
Виды Subdomain: Core, Generic или Supporting https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/
Eric Evans free Domain-Driven Design Reference https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
Vladimir Khorikov Entity vs. Value Object https://habr.com/ru/articles/275599/


Рекомендованные сайты и книги:
Domain Driven Design (Eric Evans) https://www.amazon.com/gp/product/0321125215
Implementing Domain Driven Design (Vaughn Vernon) https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577