Что такое DDD, domain-driven design? Если вы не разобрались для себя раньше, то следующие несколько записей я посвящу этой теме.
DDD это такой набор систем взглядов и подходов, который определяет cпособ разработки в целом, а прежде всего, способ анализа, постижения устройства той части мира, в которой предстоит разобраться проектировщику. В 2002 году Мартин Фаулер выпустил книгу «Шаблоны архитектуры корпоративных приложений». Книга даже на данный момент не перестала быть классикой по разработке корпоративных приложений. В частности Мартин приводит три шаблона по организации бизнес-логики в проекте:
1. Transaction script
2. Table module
3. Модель предметной области (domain module)
Transaction script – такой способ организации бизнес-логики, когда всю бизнес-логику мы разделяем на несколько бизнес-функций – фактически типовые повторно-используемые процедуры, которые как-то там внутри себя устроены, которым на вход поступают какие-то данные, а на выходе мы получаем результат и какие-то изменения в системе, например записи в базе данных или что-то ещё.
При достаточно сложной логике и при большом объёме приложения – этот метод плохо работает, потому что у нас получается макаронный код, «копи паст». И что намного хуже – при такой организации конкретная прикладная логика распределяется по всей кодовой базе – однажды определённая функция может понадобиться какой угодно другой, и если мы организуем вызов одной из другой – значит, мы связываем их тесно с риском сломать вторую при правках первой (или копипастим логику со всеми рисками этого решения).
Table module – это чуть другой подход. Он заключается в том, что мы выделяем классы-сущности, которые так или иначе обозначают таблицу интересующих нас понятий, фактически таблицы базы данных. Иногда к каждой таблице, кроме класса, сопоставляется (достаточно механически) некоторый другой код и классы – кроме сущности Zzz, появляются ZzzDao, ZzzRepository, ZzzManager, ZzzHelper и так далее.
Все классы обладают какими-то операциями, они что-то уже умеют, что-то в себе инкапсулируют. Как правило, они инкапсулируют работу с базой данных. В частности – могут содержать методы: добавить, удалить, получить все записи, и ещё какие-то. Ну и с каждой сущностью мы работаем, запрашивая из таблиц. Очевидно, прямой связи (в терминах кода) у нас между таблицами нет, и мы как-то внутри нашей программы строим их вручную там, где это надо.
Иногда к этому подключается и ORM, который как-то упрощает ситуацию, уменьшая количество рукописного кода. Но, фактически, если кто-то работал с MS Visual Studio или вообще с технологиями MS, — это то же самое, что RecordSet, или DataSet, только написанный вручную. До 2008 года это были основные технологии по работе с данными.
Ну и третий способ - модель предметной области, domain model. Отличается от предыдущих представленных вариантов тем, что здесь мы строим полноценную модель предметной области, отражающую реальный мир.
Которая состоит из сущностей, обладающих поведением, которые взаимодействуют с другими сущностями, имеют явно прописанные отношения и т.п. Сущности это такие понятия, которые имеют идентичность. Т.е. каждый экземпляр сущности может быть идентифицирован и отличается от других, и инкапсулирует в себе состояние объекта и его поведение. Это значит, что никак внешним образом мы не можем, не сообщив объекту о том – поменять его состояние, привести его к не консистентному состоянию, или заставить его вести себя как-то так, как он вести себя не должен. Этот шаблон является наиболее удачным, для применения в сложных информационных системах. Потому что он наиболее удачным образом структурирует предметную область и способствует нашему пониманию.
DDD это такой набор систем взглядов и подходов, который определяет cпособ разработки в целом, а прежде всего, способ анализа, постижения устройства той части мира, в которой предстоит разобраться проектировщику. В 2002 году Мартин Фаулер выпустил книгу «Шаблоны архитектуры корпоративных приложений». Книга даже на данный момент не перестала быть классикой по разработке корпоративных приложений. В частности Мартин приводит три шаблона по организации бизнес-логики в проекте:
1. Transaction script
2. Table module
3. Модель предметной области (domain module)
Transaction script – такой способ организации бизнес-логики, когда всю бизнес-логику мы разделяем на несколько бизнес-функций – фактически типовые повторно-используемые процедуры, которые как-то там внутри себя устроены, которым на вход поступают какие-то данные, а на выходе мы получаем результат и какие-то изменения в системе, например записи в базе данных или что-то ещё.
При достаточно сложной логике и при большом объёме приложения – этот метод плохо работает, потому что у нас получается макаронный код, «копи паст». И что намного хуже – при такой организации конкретная прикладная логика распределяется по всей кодовой базе – однажды определённая функция может понадобиться какой угодно другой, и если мы организуем вызов одной из другой – значит, мы связываем их тесно с риском сломать вторую при правках первой (или копипастим логику со всеми рисками этого решения).
Table module – это чуть другой подход. Он заключается в том, что мы выделяем классы-сущности, которые так или иначе обозначают таблицу интересующих нас понятий, фактически таблицы базы данных. Иногда к каждой таблице, кроме класса, сопоставляется (достаточно механически) некоторый другой код и классы – кроме сущности Zzz, появляются ZzzDao, ZzzRepository, ZzzManager, ZzzHelper и так далее.
Все классы обладают какими-то операциями, они что-то уже умеют, что-то в себе инкапсулируют. Как правило, они инкапсулируют работу с базой данных. В частности – могут содержать методы: добавить, удалить, получить все записи, и ещё какие-то. Ну и с каждой сущностью мы работаем, запрашивая из таблиц. Очевидно, прямой связи (в терминах кода) у нас между таблицами нет, и мы как-то внутри нашей программы строим их вручную там, где это надо.
Иногда к этому подключается и ORM, который как-то упрощает ситуацию, уменьшая количество рукописного кода. Но, фактически, если кто-то работал с MS Visual Studio или вообще с технологиями MS, — это то же самое, что RecordSet, или DataSet, только написанный вручную. До 2008 года это были основные технологии по работе с данными.
Ну и третий способ - модель предметной области, domain model. Отличается от предыдущих представленных вариантов тем, что здесь мы строим полноценную модель предметной области, отражающую реальный мир.
Которая состоит из сущностей, обладающих поведением, которые взаимодействуют с другими сущностями, имеют явно прописанные отношения и т.п. Сущности это такие понятия, которые имеют идентичность. Т.е. каждый экземпляр сущности может быть идентифицирован и отличается от других, и инкапсулирует в себе состояние объекта и его поведение. Это значит, что никак внешним образом мы не можем, не сообщив объекту о том – поменять его состояние, привести его к не консистентному состоянию, или заставить его вести себя как-то так, как он вести себя не должен. Этот шаблон является наиболее удачным, для применения в сложных информационных системах. Потому что он наиболее удачным образом структурирует предметную область и способствует нашему пониманию.