Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>А что значит никакого поведения, если он состоит из мн-ва сложных объектов со сложным поведением?
S>>Как поведение "состоять из" поможет в поведении поехать прямо? Нам же не только нужно что-то перечеслять,
S>>но и взаимодействовать и управлять этим надо. Вот абстаркция Car по заветам ООП все это дело, всю эту сложность,
S>>прячет под, каламбур, капот. Кому-то и "состоять из" понадобиться, кому-то ехать вперед и рулить.
S>Это — опасное заблуждение. Во-первых, задача "ехать прямо" или там "рулить" не имеет никакого отношения к деятельности, к примеру, автосалона.
S>Из того, что он продает авмтомобили, вовсе не следует, что надо бежать и реализовывать класс "автомобиль", экземпляры которого будут сложным образом взаимодействовать с запчастями этого автомобиля.

Ну вот так оно в реальном мире работает -- делали для автосалоно, а по итогу надо, чтобы ездило, да еще вчера должно
быть сделано. И вот как "состоять из" тут поможет? Обходить все узлы и что-то с ними делать для\при движении? Или
просто вызывать высоуровневые методы "ехать (прямо\влево...)"?

S>Во-вторых, даже если у вас действительно есть задача автоматизации управления автомобилем, инкапсуляция физики внутрь иерархии объектов очень вряд ли будет конструктивным способом решения этой задачи.

Проще для CarAssemly с api "состоять из" -- да, для тех, кому нужно ехать -- едва ли.

S>Поэтому перед тем, как рассуждать о поведении, нужно сначала озаботиться постановкой задачи. А не бежать слепо моделировать реальный мир при помощи иерархий классов и взаимодействия объектов.

Нужно было CarAssemly, а, внезапно, появился заказчик, которому нужно еще и ехать (а может и вовсе только ехать, нужен гоночный автомобиль, а не выставочный, куча денег на кону). Оно так чаще всего и бывает.

Здравствуйте, gandjustas, Вы писали:

S>>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
G>Для этого утверждения нет никаких доказательств.

Был неточен -- не обновлят строки в бд, а править BL vs правки, по сути, sql скрипта.

Здравствуйте, Sinclair, Вы писали:


S>>Почему, как репозиторий зависит от физического хранилища?
S>Примерно полностью. Вообще сама по себе идея "мы тут ворочаем доменными сущностями, а весь ваш персистенс — это какая-то внешняя забота" — порочна.
S>На её основе невозможно написать эффективную реализацию.

Ну так в видео из Я ровно про это и говорится -- проблемы с производительностью могут быть, но зато сделают
все быстро, управляемая сложность и т.п.

S>Внезапно оказывается, что хранить всю модель домена в JSON-файле, или в RDBMS, или во внешнем REST-сервисе — это три большие разницы.
S>В первую очередь потому, что эти три вида хранилищ обеспечивают крайне разную асимптотику при выполнении одинаковых запросов. И то, что в одной реализации делалось за O(logN), в другой может упереться в O(N²).

Все так.

S>>А при чем здесь DDD? Здесь побочный разговор на тему проверки инвариантов в случае, когда данные хранятся в бд.
S>>Я так понимал суть вопроса.
S>При том, что в DDD предписывается такое место этой проверки инвариантов, что оно требует подъёма половины базы в память для выполнения точечной операции.

А почему на стороне бд это не сделать эффективно и получит только необходимые цифры по итогу?

S>>Речь про транзакции?
S>Речь про запросы. В БД я могу проверить подобные предикаты, не поднимая в память сервера приложений вообще никаких данных. Часть предикатов я вообще могу проверять декларативно.
S>Более того — если окажется, что проверка поднимает слишком много данных в память СУБД, то у меня есть богатый набор инструментов по борьбе с этим не нарушая семантики — например, создание индексов, партиционирование таблиц и прочая DBA-магия. В DDD мы тащим всё это туда, где обработка будет иметь максимальную стоимость.

См. выше вопрос.

Здравствуйте, Sharov, Вы писали:

S>Ну вот так оно в реальном мире работает -- делали для автосалоно, а по итогу надо, чтобы ездило, да еще вчера должно
Нет, так не работает, и работать не может. Как максимум — можно доить заказчика, обманывая его по поводу достижимых результатов.
Система регистрации пассажиров на рейс и автопилот для самолёта — это совершенно разные программы, решающие разные задачи, и устройство у них совершенно разное.
Тот, кто это не понимает — идиот. Тот, кто понимает, но убеждает заказчика, что можно одной "моделью" решить обе задачи — негодяй.

S>просто вызывать высоуровневые методы "ехать (прямо\влево...)"?
Отлично. И как эти методы будут устроены? Будут рекурсивно вызывать аналогичные методы у всех компонентов?
И вот у нас уже двигатель должен уметь выполнять команду "ехать влево". Чувствуете, как быстро наступает абсурд?

S>>Во-вторых, даже если у вас действительно есть задача автоматизации управления автомобилем, инкапсуляция физики внутрь иерархии объектов очень вряд ли будет конструктивным способом решения этой задачи.
S>Проще для CarAssemly с api "состоять из" -- да, для тех, кому нужно ехать -- едва ли.
А там нет никакого API. "Состоять из" вообще не относится к автомобилю. В какой-нибудь инверсной кинематике есть модель системы, в которой нет ни наследования, ни инкапсуляции, ни полиморфизма.
Есть только шарниры и сочленения, с очень узким, заранее известным набором типов и характеристик.
Чтобы описать поведение автомобиля с прицепом, не нужно делать никаких "классов" — нужно просто записать модель автомобиля в кинематических терминах, и всё.

S>Нужно было CarAssemly, а, внезапно, появился заказчик, которому нужно еще и ехать (а может и вовсе только ехать, нужен гоночный автомобиль, а не выставочный, куча денег на кону). Оно так чаще всего и бывает.
И в таком подходе нужно чётко понимать, что рич-DDD-модель вообще никак не помогает решить эту задачу. Скорее наоборот — затрудняет.
Поэтому добавить в CAD-систему сопромат — нетрудно, если в её основе лежит анемик-модель, которая просто агрегирует точки/линии/грани/тела.
И практически невозможно, если в основе лежит рич-модель, в которой параллелепипед отнаследован от куба.

Здравствуйте, Sharov, Вы писали:


S>А почему на стороне бд это не сделать эффективно и получит только необходимые цифры по итогу?
Потому что тогда у вас нет никаких гарантий про семантику. Кто-то пошёл и поменял java-код вычисления бонусов сотрудникам. На страничке профиля сотрудника цифры новые, а в отчёте, который был наговнокожен "мимо" рич-модели — старые.

S>См. выше вопрос.
См. выше ответ. В СУБД встроены всякие клёвые гарантии — вроде того, что запрос при исполнении через индекс даст тот же результат, что и при исполнении через table scan. Только быстрее.
А когда я пишу два разных алгоритма, один из которых императивно обходит граф объектов, строя результат, а другой срезает какие-то углы, то у меня нет примерно никакого способа гарантировать совпадение результатов.

Это всё было ещё на заре времён — модель CODASYL появилась до реляционной; и выкинули её ровно по этой причине — нет надёжной механики алгебраических трансформаций, сохраняющих инварианты.
В итоге анемик как раз и даёт способ отделить схему "данных" от "трансформаций", и оптимизировать эти трансформации с гарантией сохранения семантики.
И при этом он не ограничен убогими выразительными способностями SQL, в котором почти ничего нельзя повторно использовать.

Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>А что здесь говорить? Всё зависит от задачи, в некоторых можно и DbContext из контроллера дёргать
А в каких нельзя?

A>Модель еf core -- это модель конкретной БД, пытаться изобразить на ef core модель домена, если она отличается, -- плохая затея.
У самого ef такого ограничения нет. Это у вас в голове.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
G>>Для этого утверждения нет никаких доказательств.
S>Был неточен -- не обновлят строки в бд, а править BL vs правки, по сути, sql скрипта.
Но и этому тоже нет никаких доказательств.