В статье будут проведены аналогии между предметно-ориентированным проектированием и математическим моделированием

Математическое моделирование

С математическим моделированием школьники знакомятся в 7 классе общеобразовательной школы. Грубо говоря, это перевод задачи из неформального человеческого языка на язык математики для последующего её решения.

(1)
Петя и Вася съели за ужином три яблока. Петя съел в два раза больше, чем Вася. Сколько съел каждый?

(2)
Пусть х - число яблок, которые съел Петя
у - число яблок, которые съел Вася

Тогда:

(3)
х + у = 3
х = 2 * у

Решаем систему линейных уравнений:

х = 2, у = 1

Здесь:

(1) - постановка задачи в предметной области
(2) - математическое моделирование
(3) - математическая модель

Другой пример из мира физики - надо посчитать, сколько топлива нужно, чтобы слетать на Луну и обратно. Есть Законы Ньютона движения небесных тел, есть данные по топливу, ТТХ ракетоносителя, массе Земли, Луны, Солнца, рассчитанной траектории и прочая информация.

Вся мощь математического аппарата - в отсутствии семантики. Ему всё равно, яблоки он считает, или траекторию ракеты. Это формализованная система, которая оперирует бездушными символами по установленным правилам. У арифметики свои правила, у алгебры - свои, у евклидовой геометрии - свои.

Достижения естественных наук зависят от того, насколько они точно и полно построят математические модели для своих задач. Если не указать массу Луны, невозможно будет дать ответ на вышеуказанную задачу. С другой стороны, если предложенная траектория математически окажется недостижимой, физики должны будут поменять её.

Математическая модель является общей проекцией решаемой задачи со стороны физики и стороны математики в некое пространство.

Предметно-ориентированное проектирование (domain-driven design)

Данную методологию предложил 20 лет назад Эрик Эванс в своей известной "большой синей книге": Предметно-ориентированное проектирование. Структуризация сложных программных систем

Для многих DDD, это когда если ты, например, делаешь онлайн-магазин, то у тебя должны быть классы Product, ShoppingCart и т.п., то есть, сущности в коде должны как бы соответствовать бизнес-сущностям. Это совсем не про DDD.

Основная задача, которую Эрик Эванс ставил при создании своей методологии - дать возможность создавать архитектуру программы так, чтобы с максимальной вероятностью удовлетворить требования заказчика и построить понятную, поддерживаемую и расширяемую систему. Получить качественный и успешный программный продукт.

В основном DDD нацелена на сложные нетиповые задачи с нечеткими/меняющимися требованиями, для минимизации рисков потратить кучу времени и денег, и в итоге не получить то, что можно использовать.

При каскадной разработке (waterfall) заказчик дает четкие требования бизнес-аналитику, по ним строится архитектура системы, программисты делают по ней код.

При гибкой (agile, XP, итеративная) заказчик дает общие требования, по ним строится прототип архитектуры системы, программисты делают по ней код, систему показывают заказчику, вносятся корректировки, выпускается следующая версия и.т.д по кругу.

В случае DDD совместная работа между специалистами предметной области (со стороны заказчика) и программистами идет всё время разработки. Связующим звеном между ними является модель предметной области (domain model) и единый язык (ubiquitous language). Это главные стратегические артефакты в книге Эрика Эванса.

Основная суть доменной модели - быть постоянной проекцией решаемой задачи со стороны заказчика и стороны разработчиков в некое общее пространство. Все, что есть в доменной модели, должно быть отражено в архитектуре программы. И наоборот, - если программист обнаруживает, что какое-то бизнес-правило невозможно применить или лучше сделать иначе, он обязан открыть дискуссию по этому поводу и инициировать внесение изменений в доменную модель, не делая попыток просто написать "как правильно".

Доменная модель сама по себе лишена семантики, она записывается с помощью UML диаграмм и документации. Семантику ей даёт единый язык, на котором происходит коммуникация всей команды (включая заказчика). Каждый термин доменной модели должен пониматься одинаково всеми участниками.

Перевод термина "ubiquitous" на русский язык как "единый" - не совсем полный. Можно добавить: "повсеместный".

Параллели

Аналогия с приведенным выше примером космического полета:

• математическая модель = доменная модель

• физика = единый язык

• математический аппарат = разработка ПО

• математическое моделирование = процесс выработки доменной модели

Важно отметить, что как в первом случае отступление математиков от поставленной математической модели легко приведет к неверному/ненужному результату, так и во втором, отступление разработчиков от доменной модели может привести к неудаче в итоге.

В своей книге Эрик Эванс дает следующий пример из реальной жизни. В Internet Explorer раньше "Избранное" сохраняло в виде файлов с именами, соответствующими названиям страниц. Когда пользователь пытался указать свое имя, то иногда попадал на ошибку "Недопустимое имя файла", хотя причем тут файл было неочевидно. Это произошло из-за того, что разработчики использовали свою модель, а заказчик хотел нечто другое.

Можно отметить, что ни в какой другой парадигме проектирования в сфере разработки програмных систем нет такого жесткого требования наличия точной общей модели как основы успешности проекта.

Таким образом, можно сделать вывод, что за парадигмой проектирования Domain-Driven Design стоит сильная идея математического моделирования