Предметно-ориентированное проектирование

Проектирование предметной области - этап проектирования архитектуры программного обеспечения.

На данном этапе мы должны иметь возможность обсуждения идей реализации продукта,

еще до того как будет написан код.

В методологии DDD предметная область описывается сущностями и их отношениями.

Рассмотрим 3 основных вида отношений между сущностями: является (is), содержит (has), использует (uses).

Примеры:

Автомобиль является транспортным средством.

Автомобиль содержит двигатель.

Водитель использует автомобиль.

Отношения

Отношение «является» (is)

Отношение «является» показывает общность поведения сущности. Данное отношение должно соответствовать принципу подстановки Барбары Лисков (LSP)(буква L в SOLID).

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

Примеры

Автомобиль является транспортным средством.

Грузовик является транспортным средством.

Транспортное средство можно завести.

Принцип LSP означает, что любая функция, использующая метод Транспортное средство.завести() не должна зависеть от того, какого типа конкретный экземпляр транспортного средства передан.

Отношение «содержит» (has)

Отношение «содержит» определяет состав сущностей.

В описании сущности следует приводить не все ее свойства, а только существенные в данной ситуации. Описывая состав сущности, мы мысленно «разбираем» ее на части. При этом, как правило, используется такой приём: сначала называется небольшое число крупных частей, затем каждая из них «разбирается» на части поменьше и так далее.

Отношение «использует» (uses)

Отношение «использует» описывает случай, когда сущности не связаны напрямую, а используется в качестве аргументов.

Стоимость

Предметно-ориентированное программирование вносит определенные издержки на проектирование и реализацию сущностей. Проектировать предметную область следует по принципу необходимого и достаточного усложнения, так любая избыточная сложность усложняет понимание. Хороший пример итеративного усложнения предметной области можно увидеть в главе Accounting Patterns книги Analysis Patterns Мартина Фаулера.

Цели

Целью внедрения DDD и принципов SOLID — перестать разрабатывать хрупкий код, ломающийся от каждого изменения. В конечном итоге применение DDD совместно с TDD должно снизить стоимость сопровождения программных продуктов (снизить количество тикетов после релизов, облегчить раннюю диагностику ошибок на этапе разработки).

Принципы разработки

  1. SOLID, см. «Чистый код», «Чистая архитектура» Роберта Мартина

  2. Сущности должны отражать моделируемую предметную область

  3. Ограничивайте изменяемость (final в Java)

  4. Чистая логика. Отделяйте бизнес-логику от других слоев приложения (сущности не должны не иметь методов работы с БД, сетью). Сущности могут иметь аннотации (spring, persistance и другие. Наличие аннотаций не является препятствием для того, чтобы создать нужные объекты для теста)

  5. Создавайте небольшие сущности для конкретных действий (Single Responsibility в Solid). Даже незначительные изменения в больших классах могут быть не тривиальной задачей. Избегайте GOD-объектов с бесконечной функциональностью, они являются копилкой технического долга.

  6. Для работы с БД и сетевыми ресурсами используются репозитории, шлюзы и т. п., с возможностью создания заглушек («mocks») для тестирования.

Чистая логика

Чистая функция обладает следующими свойствами:

  1. является детерминированной;

  2. не обладает побочными эффектами (не работает с глобальными переменными, базами данных, файлами, сетью).

Вы должны моделировать большую часть вашей логики чистыми функциями (классами) для того, чтобы она могла быть повторно используемой и тестируемой.

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

Инструменты проектрования

  1. Umbrello

  2. Плагин NetBeans Jeddict (только для хранимых сущностей)

  3. PlantUML, плагин NetBeans и web-сервер для рисования диаграмм в браузере

  4. Плагин NetBeans EasyUml

  5. ArgoUML

  6. Yed

  7. Modelio

Ресурсы

  1. Use Case DrivenObject Modelingwith UML

  2. Моделирование с помощью ArgoUML

  3. S.O.L.I.D Principles Explained In Five Minutes