Ещё бы написали, что платное/бесплатное и где скачивать. Тот же самый capitalism lab нет в нормальной крякнутой версии под windows 10 и старше, а оплатить неполучится.
Статья хорошая, но видится и обратная сторона картины - скорость создания решения может увеличится в несколько раз, из-за медленной подготовки требований со стороны аналитика. Аналитик рискует стать "бутылочным горлышком", из-за постоянным сомнений, уточнений и прочего.
Отличный вопрос! Давай разберёмся, как Domain-Driven Design (DDD) работает на разных уровнях системы:
1. DDD для архитектуры системы (макроуровень)
Здесь DDD — это стратегия организации всей системы, её компонентов и их взаимодействия.
Ключевые аспекты:
Ориентация на домен – система разбивается на ограниченные контексты (Bounded Contexts), каждый из которых отвечает за свою часть бизнес-логики.
Пример: В системе интернет-магазина могут быть контексты "Заказы", "Доставка", "Оплата", "Каталог".
Способы взаимодействия между контекстами:
Shared Kernel (общее ядро) – если контексты используют общие модели данных.
Customer-Supplier (поставщик-потребитель) – один контекст явно зависит от другого (например, "Оплата" зависит от "Заказы").
Conformist (конформист) – один контекст подстраивается под модель другого.
Anticorruption Layer (ACL) – защитный слой, который изолирует систему от чужой модели (например, при интеграции с внешним API).
Микросервисы vs Монолит
В микросервисной архитектуре Bounded Context часто соответствует отдельному сервису.
В монолите – это логический модуль (но может быть и физически выделенным).
Пример:
Допустим, у нас есть система управления логистикой.
Bounded Context "Грузоперевозки" – отвечает за маршруты, транспорт, водителей.
Bounded Context "Склад" – управление запасами, приемка/отгрузка.
Способ взаимодействия:
"Грузоперевозки" запрашивают у "Склада" данные о наличии товара через API с ACL, чтобы не зависеть от его внутренней модели.
2. DDD для кода системы (микроуровень)
Здесь DDD — это способ структурирования кода внутри одного Bounded Context, чтобы он отражал бизнес-логику.
Ключевые аспекты:
Слоистая архитектура (но не всегда!):
Domain Layer – ядро, где живут сущности (Entities), агрегаты (Aggregates), доменные сервисы (Domain Services), value-объекты (Value Objects).
Application Layer – координирует выполнение сценариев использования (Use Cases), но не содержит бизнес-логики.
Infrastructure Layer – реализация репозиториев, работа с БД, внешними API.
Паттерны проектирования внутри контекста:
Aggregate Root – главная сущность, через которую идёт всё взаимодействие (например, Order в контексте заказов).
Repository – абстракция для доступа к данным (например, OrderRepository).
Domain Events – события, которые порождает домен (например, OrderShippedEvent).
Factory – создание сложных объектов.
Пример:
В том же Bounded Context "Грузоперевозки" код может выглядеть так:
// Domain Layer
class Cargo { // Aggregate Root
private CargoId id;
private Route route;
private DeliveryStatus status;
public void assignDriver(Driver driver) { ... } // бизнес-логика
}
// Application Layer
class CargoBookingService {
private final CargoRepository repository;
public void bookCargo(CargoDetails details) {
Cargo cargo = CargoFactory.create(details);
repository.save(cargo);
}
}
Главные отличия:
Аспект DDD для архитектуры (макро) DDD для кода (микро) Фокус Разделение системы на контексты Организация кода внутри контекста Основные понятия Bounded Context, ACL, интеграции Агрегаты, сущности, репозитории Масштаб Вся система, сервисы, API Классы, методы, бизнес-правила Инструменты Event-Driven, REST/gRPC, схемы API Паттерны (Aggregate, Factory и т.д.)
Вывод:
Архитектурный DDD помогает разделить систему на логические части и правильно организовать их взаимодействие.
Кодовый DDD помогает написать чистый, выразительный код, который точно отражает бизнес-логику.
Оба подхода дополняют друг друга: без правильного разделения контекстов код превратится в хаос, а без хорошей реализации доменной модели архитектура останется лишь на бумаге.
Не совсем понятен ваш комментарий.
https://computerchess.org.uk/ccrl/4040/
Совершенно невнятная статья. Опять ИИ?
Там одна реклама...
"а вы друзья как ни садитесь..." (c)
Есть предложения по решению таких кейсов?
Ещё бы написали, что платное/бесплатное и где скачивать. Тот же самый capitalism lab нет в нормальной крякнутой версии под windows 10 и старше, а оплатить неполучится.
Выглядит интересно, но слишком большие издержки на поддержку этой истории.
ПМ/ТимЛид "вскроется" в один момент...
Набор букв...
И куча рекламы в конце - все по классике... :-)
Это была последняя статья в цикле?
А где теперь пишете, если не секрет?
Можно через ЛС.
Вот про аналитиков и гуманитарное образование сейчас обидно было...
"Лучшее - враг хорошего!" (c)
Статья хорошая, но видится и обратная сторона картины - скорость создания решения может увеличится в несколько раз, из-за медленной подготовки требований со стороны аналитика. Аналитик рискует стать "бутылочным горлышком", из-за постоянным сомнений, уточнений и прочего.
Всё хорошо в меру - нужно найти баланс.
Текст тяжеловато, для чтения, написан. Не хватает примеров, на мой взгляд.
А можно примеры промтов, которыми общались с ChatGpt?
Отличный вопрос! Давай разберёмся, как Domain-Driven Design (DDD) работает на разных уровнях системы:
1. DDD для архитектуры системы (макроуровень)
Здесь DDD — это стратегия организации всей системы, её компонентов и их взаимодействия.
Ключевые аспекты:
Ориентация на домен – система разбивается на ограниченные контексты (Bounded Contexts), каждый из которых отвечает за свою часть бизнес-логики.
Пример: В системе интернет-магазина могут быть контексты "Заказы", "Доставка", "Оплата", "Каталог".
Способы взаимодействия между контекстами:
Shared Kernel (общее ядро) – если контексты используют общие модели данных.
Customer-Supplier (поставщик-потребитель) – один контекст явно зависит от другого (например, "Оплата" зависит от "Заказы").
Conformist (конформист) – один контекст подстраивается под модель другого.
Anticorruption Layer (ACL) – защитный слой, который изолирует систему от чужой модели (например, при интеграции с внешним API).
Микросервисы vs Монолит
В микросервисной архитектуре Bounded Context часто соответствует отдельному сервису.
В монолите – это логический модуль (но может быть и физически выделенным).
Пример:
Допустим, у нас есть система управления логистикой.
Bounded Context "Грузоперевозки" – отвечает за маршруты, транспорт, водителей.
Bounded Context "Склад" – управление запасами, приемка/отгрузка.
Способ взаимодействия:
"Грузоперевозки" запрашивают у "Склада" данные о наличии товара через API с ACL, чтобы не зависеть от его внутренней модели.
2. DDD для кода системы (микроуровень)
Здесь DDD — это способ структурирования кода внутри одного Bounded Context, чтобы он отражал бизнес-логику.
Ключевые аспекты:
Слоистая архитектура (но не всегда!):
Domain Layer – ядро, где живут сущности (Entities), агрегаты (Aggregates), доменные сервисы (Domain Services), value-объекты (Value Objects).
Application Layer – координирует выполнение сценариев использования (Use Cases), но не содержит бизнес-логики.
Infrastructure Layer – реализация репозиториев, работа с БД, внешними API.
Паттерны проектирования внутри контекста:
Aggregate Root – главная сущность, через которую идёт всё взаимодействие (например,
Orderв контексте заказов).Repository – абстракция для доступа к данным (например,
OrderRepository).Domain Events – события, которые порождает домен (например,
OrderShippedEvent).Factory – создание сложных объектов.
Пример:
В том же Bounded Context "Грузоперевозки" код может выглядеть так:
Главные отличия:
Аспект DDD для архитектуры (макро) DDD для кода (микро) Фокус Разделение системы на контексты Организация кода внутри контекста Основные понятия Bounded Context, ACL, интеграции Агрегаты, сущности, репозитории Масштаб Вся система, сервисы, API Классы, методы, бизнес-правила Инструменты Event-Driven, REST/gRPC, схемы API Паттерны (Aggregate, Factory и т.д.)
Вывод:
Архитектурный DDD помогает разделить систему на логические части и правильно организовать их взаимодействие.
Кодовый DDD помогает написать чистый, выразительный код, который точно отражает бизнес-логику.
Оба подхода дополняют друг друга: без правильного разделения контекстов код превратится в хаос, а без хорошей реализации доменной модели архитектура останется лишь на бумаге.
Я палец вывихнул, пока только скроллил. Теперь пойду читать...
Спасибо.
Видимо нужно исправить на матричные/струйные, или нет?
Ну так себе подход...