ddd329

Читал эту книгу где-то в 2013-ом. Очень хороша, вот было недавно желание ее снова почитать. Так что в 2020 она всё ещё актуальная на мой взгляд.

Приветствую!

Эрик Эванс в своей книге "Предметно-ориентированное проектирование" упоминал, что разработчики нередко думают об объектах приложения в терминах таблиц баз данных. Вот у нас есть условный "Заказ", стало быть есть и таблица заказ, есть "Поставщик", значит и таблица такая. В итоге модель приложения ("домен") сливается со структурой базы данных и если вдруг приходит идея\необходимость разместить данные как-то иначе, это напрямую затрагивает модель, что как минимум нежелательно, а строго говоря - плохо.

Да, Эванс писал что-то подобное, но основной акцент у него был сделан на том, что связи, которые существуют между таблицами в БД, разработчики переносят их в модель, тем самым все усложняя.
И, приведенный вами пример, как раз это очень хорошо демонстрирует! Не нужна вам объектная ссылка между Client и Order, т.к. это разные агрегаты и каждый из них реализует свои инварианты. А вот ссылка между агрегатами в виде идентификаторов - int, Guid или чего-то другого, как раз является рекомендуемым способом.

Если можно, то отвечу чего точно не стоит смотреть/читать, так это то, когда начинают говорить что-то наподобие такого:

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

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

Ну если только один строчный комментарий. А вообще это очень плохая практика, т.к. из названия должно быть понятно что это за переменная и для чего она предназначена. Ну и соответственно нужен какой-то контекст, где это переменная используется.
Если у вас в коде визуальной формы объявлена переменная total или sum например, то конечно не понятно будет для чего они тут, а если например они объявлены в классе ЗАКАЗ, то тут понятно что это сумма заказа, т.е. мы поняли это из контекста объявления переменных...

Ну тогда АГРЕГАТ будет состоять из одной СУЩНОСТИ - City

Без ORM, есть простые шаблоны. Твой репозиторий имеет метод Save, не важно обновил или создал новый АГРЕГАТ, все это передаешь методу Save, т.е. один метод вместо двух - Add и Delete. Допустим, ты обновляешь АГРЕГАТ, который состоит из трех сущностей, а в базе существуют три таблицы, т.е. каждая сущность маппиться на свою таблицу. Та сущнсость которая представляет корень АГРЕГАТА, будет использовать оператор UPDATE в SQL запросе, а дочерние сущности надо удалить (DELETE FROM..) и вставить заново(INSERT INTO). Все это делается в одной транзации базы данных, никакой вам Unit Of Work не нужен...

Попробуйте...