Давно не писал постов на технические темы. Пора это исправить. Сегодня речь пойдет о DDD (Domain Driven Design) и полной инкапсуляции бизнес-логики в доменной модели. Каждый, кому идеи DDD пришлись по вкусу, наверняка пробовал применить их на практике и запихать всю бизнес-логику в доменный агрегат. С этим сталкиваются практически все участники на моем практическом тренинге по Spring Boot. Но среди бизнес-правил наверняка находились такие, для которых нужно было делать запрос в БД (проверка уникальности данных, сложные запросы с фильтрами и т.д.). И приходится разрываться между вариантами: 1. Вынести часть логики на уровень сервиса, что слегка ломает концепт «единого места хранения бизнес-логики». 2. Передать в доменные методы интерфейс репозитория или другие внешние порты (в терминах гексагональной архитектуры), что ломает принцип независимости доменной модели от внешних интеграций. 3. Вытащить избыточное количество данных из БД на уровне сервиса и передать их в методы доменной модели. Например, весь набор сущностей для проверки уникальности. Но это явно ударит по производительности и потребляемой памяти. Вариант 3 выглядит самым каноническим с точки зрения DDD, но допустим на практике разве что в университетских лабораторных работах или демо-проектах. Вот и приходится выбирать между вариантами 1 и 2. Лично мне чуть ближе вариант 1, но вариант 2 тоже имеет право на существование. И в этом нет ничего плохого, просто не все концепции в чистом виде реализуемы в современных реалиях. Особенно, когда разработка идёт с использованием современных развитых фреймворков, у которых не было цели быть DDD ориентированными. Поэтому, пора принять «жизненный DDD» и перестать переживать по этому поводу. P.S.: Владимир Хориков пару лет назад написал статью на эту тему и назвал данную проблему DDD трилеммой. Это как CAP теорема, которая говорит о неидеальности мира и необходимости чем-то поступиться. Кому интересно почитать, статью можно найти тут: enterprisecraftsmanship.com/posts/d…leteness