Статья хорошая, но видится и обратная сторона картины - скорость создания решения может увеличится в несколько раз, из-за медленной подготовки требований со стороны аналитика. Аналитик рискует стать "бутылочным горлышком", из-за постоянным сомнений, уточнений и прочего.
Отличный вопрос! Давай разберёмся, как 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 помогает написать чистый, выразительный код, который точно отражает бизнес-логику.
Оба подхода дополняют друг друга: без правильного разделения контекстов код превратится в хаос, а без хорошей реализации доменной модели архитектура останется лишь на бумаге.
А где теперь пишете, если не секрет?
Можно через ЛС.
Вот про аналитиков и гуманитарное образование сейчас обидно было...
"Лучшее - враг хорошего!" (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 помогает написать чистый, выразительный код, который точно отражает бизнес-логику.
Оба подхода дополняют друг друга: без правильного разделения контекстов код превратится в хаос, а без хорошей реализации доменной модели архитектура останется лишь на бумаге.
Я палец вывихнул, пока только скроллил. Теперь пойду читать...
Спасибо.
Видимо нужно исправить на матричные/струйные, или нет?
Ну так себе подход...
С open vpn так и не разобрался, где найти список стабильных серверов. Постоянно, что отваливается, или пароли меняются.
Колобок стал взрослым...
Спасибо за обзор, хотя нажимая на ссылку, я надеялся, что книг будет хотя бы 10-15.
Возраст так же скручиваете? :-)
Роль бизнес-аналитика переложить на системного... :-)
Есть определенный шарм в советской техники. Смотришь вот на такой ПК и как будто из него тебе сам Леонид Ильич рукой машет... :-)
Такой же принцип на точильном камне, верно? Т.е. с точки зрения техники заточки мусат и точильный камень идентичны?
Чем ИТБП отличается от корпоративного архитектора?