Привет, Jeffrey.
Было бы здорово если бы вы сделали скринкаст по DDD. Я уже начал изучать и читать о DDD, но это кажется мне трудным и сложным для понимания. Я верю что вы можете помочь нам лучше понять DDD.
Спасибо.
Я могу дать вам упрощённую версию DDD, с которой вы можете начать практиковаться прямо сейчас:
Для начала, DDD это не куча соглашений по коду и паттернов. DDD использует паттерны(такие как Репозиторий, Команда и тд) для достижения своей цели реализации решения проблемы, но DDD сам по себе не имеет ничего общего с написанием кода.
Я хочу подчеркнуть эту мысль ещё раз — DDD не имеет ничего общего с написанием кода.
DDD это процесс, при котором вы определяете что вы хотите построить, и как оно должно функционировать для решения проблемы вашего клиента. Как вы его реализуете это на самом деле второстепенная деталь. Что важно, так это создание модели — «шаблона» для вашей реализации решения проблемы с помощью кода.
Так что такое модель? Это абстрактное представление бизнес-проблемы/бизнес-правил вашего клиента, и модель выражена на языке который понимает и разработчик и клиент.
Так как практиковаться или применять DDD? Это на самом деле очень просто:
Вы не можете создать решение пока вы ПОЛНОСТЬЮ не понимаете проблему которую пытаетесь решить. Это похоже на то как некоторые актёры полностью сливаются с ролью которую будут играть. Как например Heath Ledger закрывал себя на месяц в комнате, чтобы подготовиться к игре в роли Джокера. И некоторые разработчики используют похожие крайности для решения проблем бизнеса. Некоторые даже получают квалификацию бухгалтера или подобную квалификацию чтобы действительно понять эту нишу. Вы не должны делать этого, но это иллюстрирует важность процесса при котором вы должны понимать проблему, которую вы решаете.
Это предполагает множество вопросов, исследований и открытий. Заставьте клиента пройти мучительный путь и максимально рассказать вам о его нише. Заставьте его показать вам как он работает, чтобы не оставалось непонятных для вас мест в процессе в котором вы будете решать проблему. Важно это всё понять, чтобы вы не моделировали излишние или ненужные процессы.
Кстати, клиентские процессы и бизнес-правила известны как домен, и ваш клиент предположительно является экспертом по домену. Но в реальности это часто не так, и для вас важно знать его процессы лучше чем он. Это поможет вам стать экспертом — сделать их проблему своей проблемой.
И это приводит к тому, что когда вы делаете приложение для себя, вы одновременно являетесь и клиентом и экспертом домена, так что тщательно продумайте проблему которую вы пытаетесь решить до того как вы начнёте моделировать решение.
Как говорилось выше, модель домена это абстрактное представление бизнес-правил и проблем клиента. По сути это означает что вы должны описать систему которую строите до того как начнёте писать код. Модель домена это мост между реальностью проблемы вашего клиента и цифровым решением этой проблемы, которую вы будете строить. Она описывает как различные части системы будут взаимодействовать и общаться друг с другом, какую информацию они будут предоставлять друг другу, какие сущности и компоненты они будут использовать, поведение которое будет сопровождать бизнес-процессы. Что важно здесь, так это не думать об этом в категориях написания кода, пока что, модель должна быть выражена в терминах бизнеса.
Важно отметить что язык, который описывает модель должен выбираться осторожно, и не обязательно должен семантично подходить под домен клиента. Вот пример из реального мира о компании для которой я делаю сайт — Клиент сейчас имеет ручную систему управления аккаунтами через телефон/email и кучу бумажной работы, и они хотят оцифровать её.
Домен клиента это коллекция процессов используемых для управления аккаунтами клиентов, управлением расписаниями, оплаты и тд. Это то что я должен превратить в модель домена в контексте того что это будет веб-сайт для реализации этих процессов.
Один из процессов — позволить клиентам управлять их аккаунтами. Эта модель уже имеет 2 сущности — клиент и аккаунты. Кроме этого понятие «аккаунт» перегружено. Аккаунты значат две вещи в цифровом мире — аккаунты в которые входит(«логинится») клиент и счета-фактуры, которые представляют сервисы за которые собственно платит клиент. В домене этого различия ещё не видно, но в модели уже должно быть видно.
И после объяснения этого клиенту, мы описали эту часть модели на таком языке: «Клиенты могут заходить в свои Аккаунты Пользователя для управления своими Счетами». Бум! Теперь у меня есть чёткое разделение этих сущностей и я знаю что я должен смоделировать некий способ коммуникации/поведения, который позволит Клиенту взаимодействовать с Аккаунтом Пользователя и своими Счетами.
И теперь понятия «Аккаунт Пользователя» и «Счёт пользователя» имеют своё значение и стали частью этого универсального языка. Ещё на этой фразе вы можете заметить что есть 2 действия «залогиниться» и «управлять». «Залогиниться» предельно ясно, но «управлять» — неоднозначно. Поэтому я разбил это понятие на несколько более мелких и эти процессы стали поведениями в моей модели.
Кстати, это совершенно нормально что модель эволюционирует и изменяется со временем. Иногда нужно несколько попыток чтобы сформировать модель. Что важно здесь так это то что модель:
-
Чётко сформулирована — вы можете описать её и её поведение простыми словами.
-
Использует последовательную, чёткую терминологию. Терминология важна — без чёткости и последовательности использования, модель сложно понять.
-
Фиксирует цель бизнеса. Это полностью даёт понять проблему.
-
Имеет недвусмысленный план того что вы должны построить. Даже если она будет изменяться и эволюционировать, вы не должны угадывать что вы должны построить и как оно должно работать.
Теперь когда вы:
- полностью знаете проблему
- имеете смоделированное понятное решение
- имеете понятный язык который описывает поведение/части решения
Вы можете начинать писать код — не важно по принципам SOLID, паттернам, или другим архитектурам. Что важно здесь, так это то, что ваше решение с помощью кода следует за моделью как если бы это был шаблон, и имена которые вы выбираете для классов и методов должны совпадать с тем понятным языком который вы использовали для описания модели.
Использование простого универсального языка жизненно необходимо. Это помогает гарантировать что код который вы пишете будет совпадать с поведением и свойствами решения которое вы смоделировали. Это значит что тесты которые вы пишете также должны совпадать с принятием критериев модели, и это значит что если у вас есть отдел тестирования, то то что они тестирует должно быть согласовано с тем как это должно работать. Это также значит что ваши строки документации должны совпадать с тем что в коде. Чтобы все были на одной волне.
DDD это процесс при котором вы должны полностью понимать проблему бизнеса и его правила (домен), вы разрабатываете модель домена — абстрактное описание решения, которое вы описываете понятным универсальным языком для описания компонентов/процессов/поведения/свойств этой модели. И потом вы начинаете писать код который следует за моделью как за шаблоном и использует тот же самый понятный язык, чтобы никто не был запутан из-за того что ваш код не идёт в соответствии с моделью.