#exp #arch #case
Хочу поделиться кейсом задачи, которую недавно решил в Github Booster. Цель - продемонстрировать, как можно развивать отдельные модули, как можно мыслить, чтобы дать импульс такому развитию.

📌 Задача

1️⃣ Использовать два кейса - syncSubscribers и syncSubscriptions для подписки на пользователей, которые подписались на целевого пользователя в Github, но на которых я не подписался в ответ.

2️⃣ Использовать два кейса - syncSubscribers и syncSubscriptions для отписки от пользователей, на которых подписался целевой пользователь, но которые не подписались на меня в ответ.

Процесс развития модулей

▶️ Уровень 1

Нарушен принцип SRP - класс SyncManager может изменяться более чем по одной причине. Декомпозируем.

▶️Уровень 2

Можно так и оставить, но мне бы хотелось абстрагироваться от каждого кейса, поэтому через Manager классы я буду вызывать Handler классы. Это поможет мне в будущем заменить один Handler на другой так, чтобы те, кто использует Manager класс, не знали об этом измении и продолжали свою работу.

▶️ Уровень 3

Все, что хотели, разделили и абстрагировали. И тут возникла циклическая зависимость, которая порождается методами subscribersBalancing и subscriptionsBalancing. SubscribersManager класс зависит от SubscriptionsManager и наоборот.

▶️ Уровень 4

Для решения проблемы циклических зависимостей делаю следующее:

Cоздаю интерфейсы SubscribersSyncManagerInterface и SubscriptionsSyncManagerInterface, чтобы Manager классы завязывались на них (выделены зеленым).

Эти интерфейсы в моем случае ведут к еще одним Manager классам, которые нужны для отдельной логики.

Если не нужно делать дополнительные действия, можно привязать эти интерфейсы к Handler классам, и проблема циклических зависимостей будет решена.

Плюсы и минусы

➕ Соблюдается принцп SRP;
➕ Есть Handler классы, которые удобно покрывать тестами;
➕ Через Dependency Injection можно переопределять детали реализации интерфейсов.

❌ Много классов;
❌ Структура проекта без конкретных правил может стать чрезмерно запутанной.

#arch #fsd #note
Дизайн с нарезкой деталей - Feature-Sliced Design или FSD

❗️ Feature-Sliced Design (FSD) — это архитектурная методология для проектирования frontend-приложений. Проще говоря, это свод правил и соглашений по организации кода. Главная цель методологии — сделать проект понятным и структурированным, особенно в условиях регулярного изменения требований бизнеса.

Проект на FSD состоит из слоев (layers), каждый слой состоит из слайсов (slices) и каждый слайс состоит из сегментов (segments).

❗️ Слои

Слои стандартизированы во всех проектах и расположены вертикально. Модули на одном слое могут взаимодействовать лишь с модулями, находящимися на слоях строго ниже. На данный момент слоев семь (снизу вверх):

1️⃣ shared - переиспользуемый код, не имеющий отношения к специфике приложения/бизнеса.

2️⃣ entities - бизнес-сущности.

3️⃣ features - взаимодействия с пользователем, действия, которые несут бизнес-ценность для пользователя.

4️⃣ widgets - композиционный слой для соединения сущностей и фич в самостоятельные блоки.

5️⃣ pages - композиционный слой для сборки полноценных страниц из сущностей, фич и виджетов.

6️⃣ processes (процессы, устаревший слой) - сложные сценарии, покрывающие несколько страниц.

7️⃣ app - настройки, стили и провайдеры для всего приложения.

❗️ Слайсы

Затем есть слайсы, разделяющие код по предметной области. Они группируют логически связанные модули, что облегчает навигацию по кодовой базе. Слайсы не могут использовать другие слайсы на том же слое, что обеспечивает высокий уровень связности (cohesion) при низком уровне зацепления (coupling).

❗️ Сегменты

В свою очередь, каждый слайс состоит из сегментов. Это маленькие модули, главная задача которых — разделить код внутри слайса по техническому назначению.

#highloadpp #video
Всем привет 👋

Недавно наткнулся на интересный доклад одного из спикеров HighLoad++ о паттернах отказоустойчивой архитектуры. Доклад очень интересный и, что самое важное, практичный. Автор рассказывает про распространенные решения, и, если вы с ними никогда не сталкивались, то самое время ознакомиться хотя бы в теории.

https://youtu.be/WWTq-tbZwUE?si=52nSg02EIUDFlGCJ

#arch #ddd
Предметно-ориентированное проектирование - (The Domain-Driven Design или DDD)

Представьте ситуацию: к вам обращается клиент с просьбой создать систему, с помощью которой он сможет управлять своим предприятием. Ему нужны модули для управления: оплатами, услугами и продуктами, сотрудниками компании, рекламными кампаниями, системой пропусков, статистикой и другим полезным функционалом.

В такой системе, по мере её роста, шанс заблудиться становиться очень высоким, и степень хаоса в проекте медленно, но верно набирает обороты:

1️⃣ чаще возникает путаница в требованиях;

2️⃣ сложно поддерживать аналитические артефакты, которыми пользуется заказчик и разработчики;

3️⃣ появляется устаревшая документация, которая может вводить в заблуждение новых разработчиков;

4️⃣ появляется много лишнего кода.

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

❗️ Предметно-ориентированное проектирование - это методология, которая предлагает последовательный алгоритм проектирования бизнес моделей системы и её бизнес правил.

В рамках этой методологии мы рассмотрим:

1️⃣ Как бизнес модель и её правила могут влиять на архитектуру приложения;

2️⃣ Принципы, формирования единого языка, на котором говорят все участники проекта;

3️⃣ Процессы эффективной дистилляции знаний о модели и её правилах.

#arch #ddd
Модель предметной области

❗️ Модель предметной области - это упрощение; это такая интерпретация реальности, при которой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются. Каждая модель должна представлять определенный аспект или какую-либо идею, представляющую интерес.

Некоторые предметные области связаны с физической реальностью. Например, в предметной области сервиса доставки еды на дом мы имеем дело с реальными людьми, ожидающими реального курьера с едой. Другие предметные области связаны с нематериальным миром. Например, это могут быть торговые крипто роботы, где операции проводятся с цифровыми активами.

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

❗️ Модели - это инструменты, предназначенные как раз для того, чтобы справиться с такой нагрузкой знаний.

Основные принципы использования модели при разработке:

1️⃣ Модель и архитектура программы должны взаимно определять друг друга. Именно тесная связь модели и её реализации определяют важность и нужность самой модели, а также гарантирует, что проделанный анализ модели отражен в её реализации - в программе;

2️⃣ Модель лежит в основе языка, на котором говорят все участники проекта. Благодаря связи модели с её реализацией разработчики могут обсуждать все связанные с программой вопросы на этом языке и общаться со специалистами предметной области без переводчика;

3️⃣ Модель - это дистиллированое знание. Она отображает только аспекты и идеи, представляющие наибольший интерес. Модель не должна содержать бесполезные или вторичные детали, знание которых не приносит существенной пользы.

#ddd #arch
Единый язык - Ubiquitous Language

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

Специалисты в предметных областях не слишком хорошо понимают технический жаргон разработчиков, но при этом пользуются собственным профессиональным жаргоном. С другой стороны, разработчики могут понимать и обсуждать систему, никак не привязываясь к тому смыслу, который вкладывают в свой язык специалисты предметной области.

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

❗️ В проекте, где нет общего языка, одним программистам приходится служить переводчиками для других программистов. Специалистам-предметникам приходится переводить своим коллегам жаргон программистов. Точность перевода и тех и других искажает понятия модели, дискуссии становятся оторваны от реальной архитектуры программы, интенсивность переработки знаний о модели падает. Помимо прочего, из-за непрямого характера коммуникации появляются "еретики" - члены команды, которые употребляют термины в неправильном смысле, сами того не понимая.

Объем требуемого перевода и риск неправильного понимания - слишком высокая цена для проекта.

Если группа разработки приложит сознательные усилия, она может сделать основой такого языка модель предметной области, одновременно привязывая весь процесс коммуникации в группе к реализации программы.

Язык на основе модели должен использоваться среди разработчиков для описания не только объектов системы, но и для задач и функциональных возможностей. Одна и та же модель должна давать разработчикам и специалистам-предметникам язык общения друг с другом, а также позволять специалистам обсуждать между собой вопросы технических требований, планирования разработки, функциональных возможностей. Чем шире единый язык в проекте, тем легче наладить плодотворное общение между его участниками.

#arch #ddd
Связь между моделью и реализацией

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

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

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

❗️ Когда программисты являются одновременно и моделировщиками, а моделировщики - программистами, происходит органичный обмен опытом и знаниями, и любой рефакторинг позволяет поддерживать актуальность модели.

В результате возникает программа, богатые функциональные возможности которой базируются на фундаментальном понимании сути предметной области, в которой она работает. А единый язык является каналом, по которому вся нужная информация расходится между программистами, специалистами в предметной области и непосредственно программным продуктом.

#arch #ddd
Модель, выраженная в программе
Чтобы суметь найти компромиссы в программной реализации и при этом не по­терять преимуществ проектирования по модели, связь между моделью и реализацией необходимо прорабатывать на уровне деталей.
В эти детали входят: ассоциации, сущности, объекты значений, службы, модули.

Когда требуется соблюсти однозначное соответствие между моделью и программной реализацией, труднее всего приходится при создании ассоциаций между объектами.

Ассоциации
❗️Ассоциации - способ связать объекты, отношения БД и компоненты. Для всякой прослеживаемой в модели ассоциации должен существовать механизм в программе. Например, внешние ключи БД, агрегаты и тд.

Существует как минимум три способа сделать ассоциации более удобными и управляемыми:

1️⃣Свести отношения к однонаправленным, прослеживаемым в одном направлении.

2️⃣Добавить квалификаторы, тем самым явно ограничивая ассоциацию. Например, от "один ко многим" до "один к одному"

3️⃣Устранить несущественные ассоциации. Например, избавиться от транзитивных зависимостей.

❗️Важно ограничить взаимосвязи до минимума. Двунаправленные ассоциации означа­ют, что два объекта можно понять только совместно, как одно целое. Если техническое задание непосредственно не требует двунаправленных отношений, то сведение их к однонаправленным снижает взаимозависимость и упрощает струк­туру программы (соблюдается принцип low coupling).

#arch #ddd
Сущности (Entities)

Сущности - логически целостный объект, определяемый совокупностью индивидуальных черт.

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

Для сущностей (в отличие от других объектов) определение через атрибуты не является главным. Иногда сущности приходится ставить в соответствие другому объекту, хотя их атрибуты отличаются. Или же сущность требуется отличать от другого объекта, хотя их атрибуты могут быть одинаковыми.
Сущность - это все то, что сохраняет свое индивидуальное существование и отличие на протяжении срока "жизни", независимо от атрибутов.

При реализации программы необходимо придерживаться следующих правил:
❗️Следует ограничить определение объекта-сущности наиболее неотъемлемыми его характеристиками, т.е. теми, которые однозначно выделяют его среди других и обычно используются для его поиска и сравнения.
❗️Задавайте только те рабочие функции, которые существенны для создания понятия об объекте, и только те атрибуты, которых требуют эти функции.
❗️Все атрибуты и функции, которые выходят за эти рамки, старайтесь выносить в другие объекты, ассоциированные с главной сущностью. Некоторые из них тоже будут сущностями, а некоторые - объектами-значениями (о них мы поговорим ниже).
❗️Для каждого объекта-сущности должен быть задан способ сопоставления его с другим объектом - такой, который бы позволял различать их даже в случае совпадения описательных атрибутов.
❗️Идентифицирующий атрибут должен гарантировано оставаться уникальным в пределах системы, независимо от способа ее определения - в распределенной системе и в архиве.

Кроме индивидуальности и непрерывно­сти существования, для сущностей часто характерно то, что они выполняют свои функ­ции, координируя операции объектов, которые им принадлежат.

#arch #ddd #exp
Объект-значение (Value Object)

Объект-значение - это объект, которыи‌ представляет описательныи‌ аспект предметнои‌ области и не имеет индивидуального существования, собственной идентичности. Такие объекты создаются в программе для представления тех элементов проекта, о которых достаточно знать только, что они собои‌ представляют, но не кем именно они являются.

Правила проектирования объектов-значений:
❗️Нужно различать, когда и что использовать (сущность, объект-значения), чтобы специальные приемы работы с объектами использовались только тогда, когда нужно.
❗️Если элемент модели полностью определяется своими атрибутами, то его следует считать объектом-значением.
❗️Сделаи‌те так, чтобы он отражал смысл заложенных в него атрибутов и придаи‌те ему соответствующую функциональность.
❗️Считаи‌те такои‌ объект неизменяющимся. Изменение значения (value) может привести к повреждению объекта-владельца путем искажения его инвариантов.
❗️Не даваи‌те ему индивидуальности, вообще избегаи‌те любых сложностеи‌, неизбежных при программном управлении сущностями.

* В своей практике я сталкивался с объектами-значениями в системе. Но лично мне кажется, что это бомба замедленного действия 🤌

#arch #ddd
Службы (Service)

В прикладной предметной области существуют операции, которые по причине сложности или определенной функциональности нельзя отнести к Сущностям или Объектам значений. Для таких объектов существует понятие модели, называемое Службами.

В программном продукте понятие Службы используется на разных уровнях, и их следует разграничивать в соответствии с функциональностью слоев:

❗️Инфраструктурный слой - технические службы без доступа к бизнес логике.
❗️Операционный слой - службы, которые “взаимодействуют” с пользователем.
❗️Доменный слой - службы, охватывающие предметную модель без доступа к функционалу, доступному пользователю напрямую.

Хорошая Служба обладает тремя свойствами:
1️⃣Объект службы нельзя отнести ни к объекту-сущности, ни к объекту значения.

2️⃣Определена собственным интерфейсом внутри доменного слоя.

3️⃣Операция не имеет собственного состояния.

#arch #ddd
Модули (Module)

Модули используют все, но мало кто воспринимает их как полноценные структурные составляющие модели. Код подразделяют по разным критериям на всевозможные виды структурных элементов: от отдельных аспектов технической архитектуры до рабочих заданий конкретных разработчиков.

На уровне предметной области Модули должны соответствовать смысловым частям модели, выражая суть и структуру модели в крупном масштабе.

Как и все остальное в искусстве DDD, Модули являются механизмом коммуникации. <...> Если вы помещаете несколько классов в один Модуль, вы тем самым гово­рите вашему преемнику, которому предстоит изучать эту архитектуру: думай о них вместе, как о целом. Если ваша модель рассказывает историю, то Модули - это ее главы.

Эрик Эванс

При проектировании Модулей придерживайтесь следующих правил:

❗️Добивайтесь низкой зависимости модулей друг от друга, чтобы понятия в разных модулях можно было анализировать и воспринимать независимо друг от друга.
❗️Дорабатывайте модель до тех пор, пока в ней не возникнут естественные границы в соответствии с высокоуров­невыми концепциями предметной области, а соответствующий код не разделится соответствующим образом.
❗️Дайте модулям такие имена, которые войдут в Единый язык. Как сами Модули, так и их имена должны отражать знание и понимание предметной области.

#arch #ddd #exp
Ловушки инфраструктуры

😡 Архитектуру диктует фреймворк
Сильное влияние на проектные решения по организации пакетов оказывают технические среды программирования. В некоторых случаях структуру архитектуры диктует используемый в команде фреймворк, размягчая мозг разработчика так, что он уже не заботится об отражении модели в программе.

😐 Разработчики переборщили
В другом случае, команда разработки создает такую архитектуру (например, многоуровневую), что обязанности одного объекта-модели размазываются между несколькими модулями (или слоями) программы. На этом этапе мысленно собрать все части объекта модели в одну концептуальную единицу становится почти невозможным, вследствие чего отраженная модель в программе либо понимается частично, либо не понимается совсем.

🫰 Вылезаем из болота
Если вы испытываете сложности с отражением модели предметной области в вашей программе, убедитесь в том, что правила построения архитектуры не слишком жесткие, а также что ваша программа не содержит чрезмерное количество обязательных пакетов.

😒 И снова low coupling + high cohesion
Иногда для формирования пакетов, способных отразить модель, достаточно соблюдать правила высокой внутренней связности и низкой внешней зависимости пакетов (low coupling and high cohesion).

#arch #ddd
Управление объектами системы

Спроектировать и внедрить “правильные” объекты архитектуры недостаточно - объектами необходимо управлять, и здесь могут возникнуть трудности, такие как поддержание целостности объекта на протяжении жизни или излишняя сложность в управлении циклом существования объекта. Решать эти проблемы DDD предлагает с помощью агрегатов, фабрик и хранилищ.

В чем ценность данных шаблонов?

Каждый объект имеет свой цикл существования. Объект “рождается“, затем проходит ряд сменяющихся состояний, а потом “умирает“ - либо удаляется, либо помещается в архив. Моделирование Агрегатов с добавлением в программу Фабрик и Хранилищ дает нам возможность манипулировать объектами систематически, в естественных смысловых границах, на протяжении всего цикла их существования.

❗️Агрегаты обозначают область действия, в пределах которой на каждом этапе жизненного цикла должны удовлетворяться определенные инварианты. Они помогают избавиться от хаотической путаницы разнообразных объектов, четко определив права собственности и границы. Этот шаблон играет решающую роль в поддержании целостности объектов на всех этапах их существования.

❗️Фабрики используются для создания и восстановления сложных объектов и Агрегатов с сохранением инкапсуляции их внутренней структуры.

❗️Хранилища отвечают за середину и конец жизненного цикла объектов - они позволяют находить и извлекать постоянно хранимые объекты, при этом инкапсулируя гигантскую инфраструктуру, стоящую за этими операциями.

Хотя Хранилища и Фабрики непосредственно не происходят из предметной области, они играют важную смысловую роль в ее архитектуре, помогая удобно обращаться с объектами при Проектировании по модели.

Каждый из паттернов заслуживает детального рассмотрения.

#arch #ddd
Агрегаты (Aggregate)

При внесении изменений в объекты модели, обладающей сложной системой ассоциаций, трудно гарантировать согласованность этих изменений. Необходимо соблюдать инварианты, относящиеся к тесно связанным группам объектов, а не отдельным объектам. Но если применить слишком осторожные схемы блокирования, то параллельные пользователи станут невольно мешать друг другу, и это сделает всю систему неработоспособной.

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

Агрегаты - совокупность взаимосвязанных объектов, которые мы воспринимаем как единое целое с точки зрения изменения данных.

У каждого Агрегата есть корневой объект и есть граница. Граница определяет, что находится внутри Агрегата. Корневой объект - это один конкретный объект-сущность, на который могут ссылаться внешние объекты, в то время как объекты, заключенные внутри границы, могут ссылаться друг на друга как угодно.

Для реализации Агрегатов в программе необходимо соблюдать правила, выполняющиеся для любой транзакции:

❗️ Группируйте Сущности и Объекты-значения в Агрегаты и определяйте границы каждого из них.

❗️ Корневой объект. Выберите один объект-сущность и сделайте его корневым. Осуществляйте все обращения к объектам в границах Агрегата только через его корневой объект. Разрешайте внешним объектам хранить ссылки только на корневой объект. Корневой объект может передать копию объекта-значения другому объекту, и что с ней потом случится не играет роли, поскольку это не более чем значение, и оно не имеет никаких связей с Агрегатом. Корневой объект имеет глобальную идентичность и несет полную ответственность за проверку инвариантов.

❗️ Некорневые объекты-сущности имеют локальную идентичность - они уникальны только в границах Агрегата. Ссылки на внутренние объекты Агрегата следует передавать только во временное пользование, на время одной операции и только по цепочке связей через корневой объект. Поскольку доступ к объектам Агрегата контролируется через корневой объект, неожиданные изменения внутренних объектов невозможны.

❗️ Как только вносится изменение в любой объект внутри границ Агрегата, следует сразу удовлетворить все инварианты этого Агрегата.

❗️ Операция удаления должна одновременно ликвидировать все, что находится в границах Агрегата.

#exp #ddd #arch
Агрегаты на практике

Агрегаты очень интересная часть DDD, поэтому хочется дополнить теоретический пост примером и своим опытом работы с ними.

Приведу пример из финансовой области. Итак, предположим наша команда занимается выдачей займов. К нам приходит Иван Иваныч, просит 100 тысяч русских долларов. Указывает все свои данные в форме на сайте, отправляет заявку на выдачу займа. Мы показываем ему несколько документов на подпись, Иваныч как-то все подписывает, переводим заявку в статус "Ожидает аудит". Проводим проверку его заявки, если все ок, то Иваныч получает деньги и начинает "жить" у нас в системе.

Пример инвариантов Агрегатов

Инвариант первый. Оформление заявки на займ.

Продолжим пример. Иваныч заполнил форму и отправил ее. В этот момент мы получили из БД инфу о пользователе (User) и создали запись о новой заявке на займ (Order) в статусе "оформление заявки" + отправили задачу на формирование документов для подписания. Чтобы не создавать все объекты по отдельности, можно реализовать агрегат (LoanAggregate) и службу для него (LoanService). В LoanService добавим метод createNewOrder(array attributes): LoanAggrate, в аргументе которого будет минимальный набор данных для создания агрегата. Сам агрегат будет обычным объектом и будет содержать инфу о User-сущности и корневой сущности Order. Чтобы сохранить агрегат в первом инварианте сделаем метод LoanService::toAwaitingDocuments, который проверит корректность данных и зафиксирует данные в БД.


Инвариант второй. Подписание документов.

Когда документы сгенерированы и мы получили коллекцию документов в коде, привязываем их к агрегату. Для сборки агрегата в актуальном инварианте используем новый метод LoanService::getLoan(userId): LoanAggregate.

Чтобы изменить инвариант агрегата на второй, в сам агрегат добавляем новый метод addDocument(Document document), а в LoanService добавляем метод toDocumentsSigning, который проверит агрегат и зафиксирует новый инвариант (подписание документов).

Инвариант третий. Ожидание аудита.

Когда LoanAggregate будет переведен во второй инвариант и Иваныч как-то подпишет документы, мы переведем агрегат в следующий инвариант с помощью нового метода LoanService::toAwaitingAudit(). Кстати, если вы храните подписи документов в объектах-сущностях, то для агрегата можно сделать новый метод addSignature(Signature signature) и дополнить сборку агрегата в Фабрике (о фабриках позже).

Надеюсь, логика изменения инвариантов агрегата стала более понятной. Количество инвариантов агрегата может быть разным, но очень важно помнить о соблюдении границ агрегата. Из опыта могу посоветовать не делать большие агрегаты и не использовать агрегаты более чем в 1-2 бизнес-процессах. В идеале использовать один агрегат для одного сложного бизнес-процесса, т.к. частные случаи в процессе могут зааффектить производительность. Даже если вам кажется, что можно переиспользовать агрегат в другом бизнес-процессе, - вам кажется 😏

#arch #ddd
Фабрики (Factories)

В значительной мере сила объекта (Агрегата) заключается в его сложном внутреннем устройстве, включая и ассоциации между его элементами. Объект следует дистиллировать, пока в нем не останется ничего, что не имеет отношения к самой его сути и его роли в транзакциях.

Если дать клиенту возможность управлять созданием объектов, это искажает архитектуру самого клиента, нарушает инкапсуляцию собранного объекта или Агрегата, а также слишком сильно привязывает клиента к конкретной реализации создаваемого им объекта.

Фабрика (Factory) - элемент программы, обязанность которого - создавать объекты.
Несмотря на то, что Фабрики могут не выполнять никаких функций в Модели предметной области, они являются элементом ее архитектуры.

Для чего нужны Фабрики:

❗️ Позволяют делегировать создание экземпляров сложных объектов и Агрегатов, облегчая их восприятие разработчиком;

❗️ Инкапсулируют внутреннюю структуру от посторонних глаз;

❗️ С помощью интерфейса дают клиенту абстракт­ное представление создаваемого объекта, не требуя ссылаться на конкретные классы при сборке.