!!! ВНИМАНИЕ DEPRECATED
Данная статья более неактуальна, потому что я успел сделать еще один скачок эволюции и перейти в сторону функциональщины, поэтому дальнейшие материалы будут выходить в рамках 2-х онлайн книг:
О чем DDD и DDD Light
DDD и DDD Light – это опыт лучших решений множества архитекторов и разработчиков, которые сталкивались с одними и теми же проблемами из-за роста их проектов.
Основная задача DDD и DDD Light – снизить сложность модификации существующего и внедрении нового функционала с ростом приложения.
? Горячий анонс ?
Вышла Open Source версия DDD Light Framework для Node.js & TypeScript: https://github.com/Dionid/dddl
Отличие DDD Light от DDD
DDD Light (DDDL) убирает множество концепций стандартного DDD в пользу скорости разработки и более быстрого вхождения в процесс новых членов команды (как разрабов, так и менеджеров), что позволяет использовать его даже при написании MVP.
Если быть еще более точным DDDL — это набор plug&play концепций. Выбирайте именно те, которые вам пришлись по душе, используйте на здоровье, учитесь применять разные концепции под разные задачи.
Из чего состоит DDDL
Основные составляющие две: (1) проектирования и (2) реализации.
Проектирование
Основная идея подхода DDD — это навык быстро вникать в контекст бизнеса, эффективно коммуницировать и решать бизнес задачи.
Мы обязательно затронем тему анализа проекта и создания из этого очень крутой и понятной документации, которая будет невероятно полезной для менеджеров и разработчиков. И когда я говорю о документации, я говорю и о тексте, и о видео материалах.
Реализация
Паттерны и методологии проектировани:
- Repository + Query Object + ORM – как способы организации доступа к источникам данных (БД, сторонние API, fs и подобное)
- Aggregate + Rich Domain Model – как способ организации Сущностей приложения и бизнес-логики
- Domain Features – как способ выделять бизнес логику в разрезе нескольких Сущностей
- Application Service – как удобный способ организации логики приложения
- Service Object – для максимизации SOLID доменной логики и логики приложения
- Латентный CQRS – как правила того что может принимать и отдавать API, а также какого рода операции можно совершать внутри API endpoint
- AOP на минималках – как удобный способ «расслоения» логики и ее повторного использования
- Backend for Frontend (BFF) – как способ агрегировать данные для frontend и делать frontend все более и более тупым, а backend более умным
- Domain и Intergratione Events – для реализации асинхронных операций и уменьшения связанности логики (а еще Saga, но об этом позже)
- Behaviour UniT Test Driven Development (BUTTDD) — название зацените, полная ебанина, но это подход к организации кода, удобного для написания минимальных, но самых важных тестов.
Когда DDDL нужен
Существует 2 основных ситуации для использования DDDL: Enterprise и Максимальная гибкость.
Enterprise
Когда вы уже достаточно большие (или знаете, что такими станете) и вам нужно решать проблемы масштабирования.
Повторюсь, DDDL – это набор plug&play концепций. Выбирайте те, которые вам пришлись по душе и используйте на здоровье. Готовые рецепты:
(произносить это вслух голосом из рекламы на диване для калечей)
- Если у вас много источников данных (БД, сторонние сервисы типа Auth0, Firebase, Hasura, партнерские API и так далее) — вам поможет связка Repository + Query Object.
- Море сложных запросов засрали вам кодовую базу? — берете Repository и получаете Query Object в подарок!
- Если у вас много входных API (пользовательский, админский и куча других REST API, боты, так еще и GraphQL просят прикрутить) – то BFF + Service Object вам в помощь
- Надоела куча «сквозной» логики засирают код операций: валидации, авторизации, логирование, транзакции, трассировка, метрики, .etc? Тогда вам нужен AOP
- Устали от мешанины внутри приложения: непонятно что где лежит, изменение в одном месте ломает все остальное, новые разработчики ссуться и плачут при виде кода — тогда пора узнать что такое Application и Domain logic, Aggregate и Rich Domain Model
- Ладно, распихали все в сервисы логику приложения и логику домена, но сервисы приложения просто жирнющие! Тогда обращаемся в сторону Service Object
- Стало сложно писать запросы к данным? Непонятно как это миксовать с моделями бизнес-логики? – CQRS в помощь
- API ведет себя непредсказуемо? – опять CQRS в помощь
- Уже не умещаетесь в CRUD? – снова CQRS
- Чтобы написать тесты на API endpoint надо поднять HTTP сервер, БД, фикстуры, Redis, избить жену, развернуть sandbox сторонних сервисов, короче, писать unit тесты невозможно? Бог вам в помощь… А еще BUTTDD
- Слишком длинные цепочки операций, в которых куча вызовов к сторонним сервисам? – Integration и Domain Events помогут вынести эту логику подальше.
- И так далее
Знаю, кажется сложным. Но внимательный взгляд заметит разветвленное дерево проблем и решений. Если вы можете предсказать какую-то ветку этого дерева на старте проекта, то можете сразу закладывать эти концепции, дальше получите плоды в виде уже готовых решений. Если нет, то ждите разрыва ануса и начинайте вводить их после.
С самого начала любого долгосрочного проекта на любом языке и framework от среднего размера, я бы всегда использовал:
BUTTDD + Service Objects + Rich Domain Model + BFF + Repository + Query Object
Остальное опционально.
Максимальная гибкость
Ситуация такая: у нас клиент забугорный, просит разработать сервис, который будет ходить за данными в DynamoDB и перекладывать в Firestore, чтобы клиентское приложение отображало их в real-time, а из Firestore денормализовывать и класть обратно в DynamoDB. А поскольку нагрузка очень большая и нужно скоростное неопределенное масштабирование нужно исползовать serverless архитектуру на aws lambda.
И, боюсь, что ни один MVC Framework не приспособлен для такой мультистэковости.
Ок, напишем без MVC. Но как тогда структурировать логику? Бить по слоям, делать запросы к данным и потом обрабатывать их?
DDD Light помогает без затруднений работать с проектами, требующими большую гибкость.
И эти принципы применимы к любому языку и области разработки: от frontend до backend, от разработки CRM до криптовалют и IoT. Поэтому узнав их один раз — вы становитесь кубервоином, способным писать крутой софт всегда и везде.
Когда DDDL использовать НЕ стоит
Во-первых, если у вас проект, который надо просто «сделать» и причем быстро: API за неделю, интернет-магазин за месяц, внутренний проект за пару дней – тогда DDDL вам не нужен.
Во-вторых, разбейте ваше ПО на модули, а DDDL используйте только там, где это нужно:
- Нужна аутентификация? Воспользуйтесь Auth0, Cognito, Ory
- Нужен менеджмент контента для системы / приложения? Раскройте какую-нибудь (Headless) CMS.
- Нужна админка? Раскрываем Django / RoR / Laravel + October CMS / AdminBro / React Admin / Retool / Directus
- Нужен CRUD / Real-time? Тогда Firebase, Hasura или какая-нибудь либа с автоматической генерацией (типа FeathersJS) к вашим услугам.
- Нужен модуль, который все это объеденит и превратит всю эту кашу в конкретный продукт (например, площадку дистанционного обучения)? Воооот тут то как раз мы и воспользуемся DDDL для написания качественного и максимально гибкого софта.
Как видим, точечное применение требующихся технологий, позволяет добиться максимального результата от каждой из них.
Что дальше?
Следующим шагом я выпущу раздел Оглавление и начну постепенно рассказывать про Entity, UseCase и Aggregate из DDD.
Новости по выходу статей ждите в Tg канале @davidshekunts_blog
На данный момент вы можете посмотреть на «DDD Light. Полезные ссылки». Там я собрал все источники откуда я все пiзжу.
