Comments 9
А зачем зеркалить модели в базу? Чистая архитектура рекомендует писать бизнес-логику так, как удобно для бизнес-домена, а база висит где-то там, за интерфейсом.
Понятно, что это идеал, часто бизнес-логика размазана по хранимкам и триггерам, но стоит ли зеркалить...
Ну как зачем? Модель создана для того, чтобы зеркалиться в базу. Это её назначение. Если мы этого не делаем, то у нас DB-first и модель нам не нужна.
Чистая архитектура рекомендует писать бизнес-логику так, как удобно для бизнес-домена, а база висит где-то там, за интерфейсом.
Так model-first и не вступает в противоречие с DDD. Они вообще на разных уровнях. Model-first решает проблему поддержки консистентности структуры базы и кода. В вашем случае можно было бы использовать, ну назовём это "3d model first". Когда предметная область задаёт структуру данных, то есть модель, а из модель подтягивает структуру БД до истинной и генерит код.
Если я правильно понимаю чистую архитектуру:
бизнес-логика - это то, чем люди будут заниматься даже при отсутствии какой-либо вычислительной техники вообще; скажем, банкиры будут считать сложный процент, а астрофизики - параметры звёзд, даже если у них останется только бумажка с ручкой; соответственно, при создании модели вообще про такие вещи, как зеркалирование, SQL, NoSQL думать нельзя, это инфицирует бизнес-логику чуждым кодом;
можно сказать, что вообще "никто не first"; Роберт Мартин особо подчёркивал (и даже гордился), что БД - это такой же легко заменяемый сегмент внешнего круга ПО, как, скажем, веб-интерфейс (с учётом реального положения дел, такое, конечно, можно встретить нечасто), и "проблемы базы шерифа не волнуют";
консистентность и правда хромает.
Но это, разумеется, только один из подходов к проектированию ПО, абсолютизировать его было бы неразумно.
Не работает эта чистейшая архитектура на практике без "инфицирования бизнес-логики чужим кодом". Начиная с простого примера - уникальности сущностей. Создаём констрейнты и в этот момент уже смешиваем слой бд с бизнес-логикой. Как мы должны поступить в чистой архитектуре? Писать код, который будет проходить по всем записям и проверять, есть ли эта сущность уже в хранилище?
бизнес-логика - это то, чем люди будут заниматься даже при отсутствии какой-либо вычислительной техники вообще;
Без вычислительной техники - возможно. Без схемы данных - неа.
Бизнес-логика просто ничего не сможет сделать без модели. У всех звёзд одни и те же параметны, но разные. Процент пишется одними и теми же цифрами по одному и тому же правилу, от такой же цифры слева от процента. И получится абсолютно прямоугольная таблица, только нарисованная ручкой.
Без структур данных действительно мало что получится. Цитируя Торвальдса, "Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимосвязях".
Но структура данных ≠ схема данных. Возможно, вам для бизнес-логики оптимально подойдёт красно-чёрное или префиксное дерево, и заранее засовывать его в прокрустово ряляционное ложе было бы, на мой взгляд, большой ошибкой.
Блин, как же приятно читать текст, написанный живым человеком!
Наша команда реализовала model-first, используя protobuf-описания в качестве модели. Из них генерируются классы на C++ и Java, из них же генерируются таблицы в базе, protobuf используется как формат сериализации. Из недостатков: нет описания связей, нам пока норм, в будущем можно будет доработать плагины, чтобы внести эту функциональность.
Спасибо. Я для написания прошлой статьи делал систему, где всё наоборот. Была модель, а из неё делались entity классы и proto-файлы. Вот репозиторий. Туда я тоже джойнов не завёз, хотя в оригинальной системе они были.
Вот парадигма есть, а инструментов - нет.
Знаю такой один, правда, завязан на постгрес
https://docs.geldata.com/reference/datamodel
(Ранее назывался edgedb)
Почему model-first и где истина?