Глубокая зависимость архитектуры приложений от дизайна базы данных - ограничение не новое - Мартин пишет очень доходчиво и подробно уже много лет. Всем рекомендую.
Наличие инструментов, способных "гнуть" структуру базы данных на уровне модели ORM годно исключительно для макетирования и ранних этапов прототипирования. Их не безопасно (речь о целостности) использовать на более поздних этапах развития (даже если оставить ORM в режиме строгой валидации схем).
Решение задачи повышения уровня абстракции можно выполнить только над моделью данных, а значит - почти во всех сервисах, которые так или иначе на неё будут опираться, её придётся раскрывать в достаточной мере: риски фрагментации архитектуры и снова безопасность, но теперь уже с ракурса доступности и конфиденциальности.
Таким образом, вопросы есть. Причём именно из позиции разработки архитектуры, обеспечивающей гибкость расширения и контролируемую стоимость владения. Аспекты: "модно-молодёжно" и "увлекательное приключение" - сейчас не берём.
О eDSL:
Не все готовы: "молодёжь", распробовшая на вкус итераторы (например, параметрические - а здесь можно ваять так, что деловые правила вообще не будут проникать в императивную логику), ещё не скоро устанет от их написания - им объективно потребуется время (я сейчас без снисхождения или иронии). Это важный опыт, который даст путь от них отказаться в будущем.
Но если готовность есть, не всё так однозначно. Этот подход действительно может не только сглаживать углы, так как секрет успеха здесь - удачный дизайн доменной модели в контексте её поведения.
Поэтому, Коллеги, появление новых подходов в этой теме:
Во-вторых, повод для анализа: так как новые пути могут открываться в процессе обсуждения, пусть и ожесточённого.
В связи с этим, нахожу подход в подчинённом задачам архитектуры (!) автоматическом (?) создании контекстной модели управления данными, который предлагает Никита, представляющей интерес историей.
Вместе с тем, статья, увы не раскрывает сути подхода на достаточную глубину, но зато говорит о "разливающейся в этом месте магии". Никита, мне не хватило деталей. Готов помочь с описанием, если найдёшь это уместным.
Тоже добавлю несколько слов в тему:
Глубокая зависимость архитектуры приложений от дизайна базы данных - ограничение не новое - Мартин пишет очень доходчиво и подробно уже много лет. Всем рекомендую.
Наличие инструментов, способных "гнуть" структуру базы данных на уровне модели ORM годно исключительно для макетирования и ранних этапов прототипирования. Их не безопасно (речь о целостности) использовать на более поздних этапах развития (даже если оставить ORM в режиме строгой валидации схем).
Решение задачи повышения уровня абстракции можно выполнить только над моделью данных, а значит - почти во всех сервисах, которые так или иначе на неё будут опираться, её придётся раскрывать в достаточной мере: риски фрагментации архитектуры и снова безопасность, но теперь уже с ракурса доступности и конфиденциальности.
Таким образом, вопросы есть. Причём именно из позиции разработки архитектуры, обеспечивающей гибкость расширения и контролируемую стоимость владения. Аспекты: "модно-молодёжно" и "увлекательное приключение" - сейчас не берём.
О eDSL:
Не все готовы: "молодёжь", распробовшая на вкус итераторы (например, параметрические - а здесь можно ваять так, что деловые правила вообще не будут проникать в императивную логику), ещё не скоро устанет от их написания - им объективно потребуется время (я сейчас без снисхождения или иронии). Это важный опыт, который даст путь от них отказаться в будущем.
Но если готовность есть, не всё так однозначно. Этот подход действительно может не только сглаживать углы, так как секрет успеха здесь - удачный дизайн доменной модели в контексте её поведения.
Поэтому, Коллеги, появление новых подходов в этой теме:
Во-первых, повод для конструктивной дискуссии: ибо, полагаю, "задолбало" всех. Особенно, Redis ;-).
Во-вторых, повод для анализа: так как новые пути могут открываться в процессе обсуждения, пусть и ожесточённого.
В связи с этим, нахожу подход в подчинённом задачам архитектуры (!) автоматическом (?) создании контекстной модели управления данными, который предлагает Никита, представляющей интерес историей.
Вместе с тем, статья, увы не раскрывает сути подхода на достаточную глубину, но зато говорит о "разливающейся в этом месте магии". Никита, мне не хватило деталей. Готов помочь с описанием, если найдёшь это уместным.