Arpanxpet_trow, спасибо.

Сколько я читал DDD, я так понял что Repository изначально и должен выдавать Aggregate Root (доменый тип) которым оперирует наша программа. А сами Entity мне по идее в чистом виде и не нужны.
Но во всем примерах стабильно идет реализация на выдачу Entity, и стабильно нет примеров для сложных/комплексных типов.
И я вот не пойму, я неправильно понял идею? Или это в примерах

Entity Framework, как и любая другая ORM, не дадут реализовать DDD в полной мере. Потому как с одной стороны, действительно, можно правильно спроектировать модель данных и получить нужные Aggregate Root, с которыми можно работать очень похожим образом на работу с доменом. С другой стороны, нет инкапсуляции, и нет никакой возможности нормально эту инкапсуляцию реализовать, поэтому это всё сплошная мишура. Остаётся только одно единственное понятие: Entity, отсюда и название. Не нужно искать стабильных примеров организации DDD на ORM, их попросту нет.

Entity Framework даёт возможность очень быстро работать с моделью данных со строгой типизацией, что даёт возможность применять LINQ, использовать атрибуты и мощный слой рефлексии поверх всего этого. Но любая динамика даст трещину. Заходите EAV? Приехали. Захотите динамические подзапросы? Привет, костыли на Expandinq expressions!

Идея здесь простая: если у вас имеется конечная хорошо нормализованная модель, подверженная изменениям только в рамках нормализации, можете пилить, и очень быстро выдавать стабильный, понятный и хорошо сопровождаемый результат. Зачастую, этого хватает.

ArpanxСейчас такой банальный вопрос, куда спрятать Join двух Entity и формирование DTO. А еще лучше посмотреть на код.

Зачем их прятать? JOIN это уже само по себе нарушение нормализации, если всё правильно нормализовано и вы живёте в идеальном мире, то JOIN не нужен, до любой сущности можно добраться через сущность, являющейся Aggregate Root

Petro123Ну и не забывайте, что технологии меняютя в 3-4 года.

Это неверное утверждение. Технологии не меняются, появляются новые, путём эволюции существующих, или переосмысление и эксперименты. Нельзя закладываться на технологии, которых ещё нет, поэтому помнить об этом бессмысленно совершенно.


Petro123Счас вон, oData и Net Core подоспели).

OData «подоспела» ещё в 2017 году

hVosttPetro123Счас вон, oData и Net Core подоспели).

OData «подоспела» ещё в 2017 году

*в 2007

ArpanxНу у меня как раз связка такая ASPNet.Core 2.0 + ORM EF PostgreSQL + Angualr 5.0 и все это работает на Linux Ubuntu

Репозиторий делаю по этому примеру Как самый простой. И тут сразу возник вопрос как, а вернее где и кто это должен реализовать формирование комплексного типа. (построить дерево на основании данных из двух таблиц)

В том то и проблема что не могу найти хороший пример с которого можно было бы содрать. Есть хорошие примеры по Clean Architecture, Гексагональная архитектура, CQRS но они настолько сложные что не могу осознать и повторить у себя, хотя бы до стадии чтобы оно компилировалось.

Хороших примеров в вакууме не существует. Когда мы проектировали архитектуру нашего последнего и текущего проекта на DDD / CQRS, выяснилось, что имеющиеся реализации фреймворков, библиотек, решений, проектов — нам не подходит ни один, даже на 20%. Но из каждого можно извлечь удачные решения, блестящие обобщения и паттерны. Было прочитано тонна литературы, статей, исследований, изучен досконально код кучи проектов, включая на других языках, и путём изысканий, набития шишек, кучи «первых блинов», был рождён рабочий проект, который даже после всех мытарств не является образцом для подражания и рефакторится раз в 2 недели набегами.

А вы хотите «хороший пример». Максимум что можно найти хорошего, это реализацию какого-нибудь алгоритма. Который влезет на один экран. Далее нужно собирать бест практикс для каждого конкретного случая, накапливать опыт, читать и кодить, кодить, кодить.

Нет никакого примера, который будет ответом на ваши вопросы.

Petro123hVosttНет никакого примера, который будет ответом на ваши вопросы.
Со всем согласен кроме этого.
Аффтар! Ответом на ваш вопрос будет Hello wold.
Добвлю imho что это MVC hello world, если вы пишите не кандидатскую или докторскую.

MVC hello world больше вредны, чем полезны.

Petro123Petro123,
Я имеё ввиду пример веб проекта с ГУИ от Net.
Неужели нет такого.
Ангуляр это не базовый школьный пример для шарп программиста.

Не, нету
Проблема школьных примеров, что реальные проекты потом делаются именно вот так, по-школьному.


Petro123VS 2015 меню - новый веб сайт.
Итого 4 типа проекта.
Так что без пессимизма).

Ну начать можно с этого, конечно. Но в итоге всё полностью меняется, так или иначе :)