Первостепенная задача разработчика — решение проблем пользователей, написание кода —только инструмент.
Проблемы, которые решают разрабатываемые продукты, могут быть в разных предметных областях, не обязательно знакомых программисту. Для решения нужно эти проблемы понимать. Другими словами, программист должен до некоторого уровня стать экспертом в предметной области.
На практике, как правило, в качестве эксперта выступает аналитик или менеджер проекта, которые берут на себя понимание проблем и потребностей, а разработчик просто пишет код по строгому техническому заданию. Однако это обычно плохо работает. Разделение компетенций приводит к потере комплексного взгляда: разработчик смотрит только с технической стороны, а аналитик или менеджер проекта — только с бизнесовой.
DDD (domain driven design) — предметно-ориентированная парадигма проектирования и разработки — помогает решить данную проблему с помощью особого подхода к проектированию и коммуникации.
Основа — воссоздание предметной области в коде через бизнес-логику, взаимодействие объектов и соотнесение реальных условий применения продукта с реализацией.
Ключевые понятия DDD
- Domain Model (Модель) — структурированные знания об определенной предметной области.
- Переработка знаний — получение информации о предметной области в понятной и структурированной форме.
- Непрерывное обучение —постоянное изучение предметной области в процессе формирования модели и общения со специалистами и пользователями.
- Единый язык —общий и понятный всем язык общения. Является хранилищем переработанных знаний о предметной области.
Domain Driven Design использует слоистую архитектуру. Её главным компонентом является смысловое ядро — Core domain — часть домена, имеющая первостепенное значение для выполнения главной задачи.
Именно в этом ядре концентрируются знания о предметной области, поверх которых потом формируются новые слои со служебной и второстепенной функциональностью.
Создавая модель предметной области, разработчик не только проектирует архитектуру под текущие бизнес-процессы, но и создает возможности для последующего расширения. Если это будет возможно в предметной области, это будет возможно и в модели этой предметной области, а значит и в ПО.
Преимущества разработки по Domain Driven Design
- Сокращает издержки на сопровождение ПО — если изменение произошло в рамках предметной области, то оно органично интегрируется и в продукт;
- Сокращает издержки на документацию — код самодокументируется, поскольку отображает реально существующую предметную область;
- Разработчики органично понимают предметную область по мере работы и постепенно становятся экспертами;
- Всесторонний взгляд на проблему помогает находить решения, соответствующие реальной ситуации.
Ошибки в модели предметной области критичны, поэтому успешная реализация требует:
- Высокой квалификации разработчиков;
- Много времени на анализ информации и построение модели;
- Совместной работы разработчика и специалиста, погруженного в предметную область.
Важно понимать, что DDD не говорит, как писать код, то есть не исключает ни одну из практик, или принципов разработки, таких как SOLID, KISS и так далее.
DDD в итеративной разработке
В итеративной разработке проект разбивается на несколько логически цельных итераций. В каждой итерации проект проходит цикл «Планирование → Реализация → Проверка → Корректировка».
Выделение смыслового ядра и проектирование по предметной области позволяют с первой итерации заложить основы «жизненной» архитектуры. Она станет основой для второстепенной функциональности и новых блоков, но не будет подвержена глобальным изменениям, поскольку изначально отображает предметную область.
Как правило первая итерация представляется собой минимально достаточное смысловое ядро — основной домен проекта и набор прикладной функциональности.
Такая реализация ограничивает первую итерацию решением только основной задачи, но позволяет начать использование продукта намного раньше по сравнению с реализацией всего и сразу. За счет этого команда получает обратную связь на самых первых этапах и может скорректировать архитектуру до момента, когда на неё окажется завязано критически много прикладной функциональности и переосмысление проекта станет слишком дорогим.
Последующие итерации предполагают расширение прикладной функциональности, но без внесения кардинальных изменений в смысловое ядро. Тем не менее оно может быть расширено за счет расширения самой предметной области. Если эти изменения получилось интегрировать в предметную область, значит и в модель предметной области их интегрировать возможно с минимальными издержками.