Если надо только передать данные из бд в объект dto, то доменная модель совершенно не нужна. Достаточно persistence object => data transfer object

Після С++ перейшов на C# та кайфував — наскільки простіше було робити деякі базові речі.

DDD — це не про архітектуру

Интересный тезис. Скорее можно сказать, что DDD говорит о многих вещах, но также безусловно и об архитектуре. В число базовых элементов DDD входят доменные модели и доменные сервисы, которые с точки зрения многослойной архитектуры входят в состав слоя logic layer. Хотя DDD не указывает как именно их надо располагать и использовать в слоях приложения.

использовать абстракцию репозитория скрывающую за собой EF если хочется чистой доменной модели

Написано уже много книг по DDD, но по-прежнему обсуждается реализация доменной модели при помощи EF или ORM в общем случае. Если речь идёт о доменной модели и тем более о чистой доменной модели, то никакого участия ORM в ней не должно быть. Или же тогда не называйте её чистой доменной моделью.

На деякі питання у статті сучасне розуміння архітектури дає досить конкретні відповіді.

домен не повинен залежати від EF Core

Модель данних домена не повинна використовуватися для взаємодії с базою данних. Для цього потрібна persistence model, яка може буди розроблена с використанням EF Core, а може и без будь-якого фреймворка.

а що саме ми виграємо, якщо сховаємо EF Core за власною абстракцією?

Типове рішення — це ховати EF Core не за власною абстракцією, а під групою об’єктів, які імплементують паттерн Data Access Object. Дуже рекомендую опис такої реалізаціі в книжці Бауэр К., Кинг Г., Грегори Г. Java Persistence API и Hibernate, 2017. Приклади архітектури и кода в розділах 18.1 и 18.2

Дуже цікава публікація. На доу вкрай мало пишуть про архітектуру. Є таке доповнення. Автор пише про багатошаровість тільки текстом, але більш наочно це зробити у вигляді малюнка з відображенням шарів та моделей даних та схеми взаємодії між ними. Наприклад послідовність «Документ -> Товарний документ -> Зовнішній товарний документ -> Видатковий зовнішній товарний документ -> Видаткова накладна» показати на малюнку у вигляді взаємодії між шарами та моделями даних. Як приклад малюнки у публікації habr.com/ru/articles/1005628

Відповідаю на Ваші зауваження.
Моя основна ідея в тому, що під application розумію автономну систему, окремі елементи якої взаємодіють безпосередньо, а не через через комп’ютерну мережу.
Саме таке application буде одно- чи багашаровим. Безумовно багатошарове application, як окремий випадок можно бути одношаровим.
В цій термінології в multi-tier application кожен tier буде грати роль окремого application.
Застосування підшар не є обов’язковим — тільки при потребі.

Якщо ми розглядаємо алгорітм Pipes and filters в межах одного application, то безумовно він весь буде всередині одного шару. Але зазвичай application потребує деякий facade layer, через який вводяться початкові дані та persistence layer, через якій результати розрахунку сберігаються у базі данних. От уже і маємо декілька шарів.

Що стосується комп’ютерних ігор — не можу нічого сказати, бо ніколи не працював з ними як розробник.

Безумовно виникає питання щодо складних систем, кожна з яких складаєтся з великої кількості компонентів. Ядро такої системи буде багатошаровим application, а компоненти будуть скоріш за все одношаровими. Але у такому випадку архітектуру треба розглядати для кожної складної системи окремо.

Дякую за розгорнуту відповідь. Коментарі дам трохи позніше.

Малюнок 4 тут habr.com/ru/articles/667922

Також можно додати що Фаулер дуже чудово викладає матеріал у своїх книгах. Можливо це заслуга літературних редакторів видавництв. Тому що статті Фаулера на його сайті написані досить топорно і дуже відрізняються по стилю від книг.

Яка велика та дуже складна книга. А от у мене все навпаки. Після багатьох років праці у айти мені вдалося звести архітектуру будь-якого application лише до однієї універсальної схеми. Хоч вона і досить складна.

Зараз описано так багато типів архитектури, що на мій погляд має сенс розробити одну таку первісну архітектуру, що всі існуючи зараз типи архитектури будуть її нащадками.

А де код та алгоритм роботи візуального інтерфейса з якого користувач працює з квитками?