Вы находитесь на правильном пути в отношении DDD в зависимости от того, насколько тонки / толсты уровни домена и службы.DDD говорит, что знания (то есть бизнес-логика) должны быть включены в модель предметной области.Перенос проблем с доступом к данным в DAL соответствует DDD, но я думаю, что перенос бизнес-логики в сервисный уровень - это не так.Если у вас тонкий слой «модели данных» домена (в основном для сущностей) и толстый слой служб (в основном для «бизнес-логики»), у вас может быть анемичный домен .
ТакжеТехнически нет "Service Layer" в DDD.Может существовать «Уровень приложений», но он должен быть тонким и отвечать только за поток приложений / время жизни классов домена.По сути, это то, что контроллеры делают в .NET MVC, управляют потоком приложений в контексте веб-http.
Если заполнение всей логики в Модели сделало ваш код слишком сложным, мне было бы интересно услышать примеры того, что вы подразумеваете под "чрезмерно сложным".Вы могли бы правильно моделировать сложную область, или есть вероятность, что вы могли бы использовать шаблоны DDD, чтобы не усложнять ситуацию.Я бы сказал, как вы перечислили это в своем вопросе, арка не DDD.Я бы просто назвал это «Многоуровневая архитектура», но это потому, что я предпочитаю использовать термин «уровень», только когда речь идет о физической дуге.Тем не менее, ваша логическая архитектура многослойна.
Мне действительно нравится, что Дарин в своем ответе связал Луковую арку.Я становлюсь большим поклонником этого, и я нахожу, что это вовсе не исключение для DDD.Если ваш код использует внедрение зависимостей для решения интерфейсных зависимостей с реализациями времени выполнения, у вас может быть форма onion arch.Например, вы определяете какие-либо интерфейсы в вашем DAL?Реализуются ли реализации этих интерфейсов во время выполнения?
Вот пример арки, которую я начинаю использовать в моих новых проектах.Это комбинация onion + DDD:
API Проект / Сборка: универсальные интерфейсы, перечисления, классы и методы расширения, используемые всеми другими слоями.Не обязательно отделяться от домена, но может.
Domain Проект / Сборка: все объекты и бизнес-логика.Зависит только от API.Используются шаблоны DDD, такие как фабрика, сервис, спецификация, репозиторий и т. Д. Также содержит больше специфичных для домена интерфейсов, которые не определены в API.
Impl Проект / Сборка: реализации интерфейсов, определенных в API и Domain.Именно здесь реализован EF DbContext, а также такие вещи, как ведение журнала, отправка электронной почты и т. Д. Все эти реализации внедряются в зависимости, поэтому технически у вас может быть несколько проектов / сборок Impl.
UI Проект / Сборка: Это проект MVC.Контроллеры потребляют поверхность домена напрямую и не проходят через уровень приложения или службы.Любые зависимости интерфейса на фабриках, в сервисах, репозиториях и т. Д. Вводятся в домен контроллером с помощью MVC IoC (внедрение конструктора).
Я поместил уровень API в самое ядро, но вы можете объединить проекты API и домена в один.Так или иначе, большая мясистая часть лука - Домен, и у этого есть внутреннее наслоение.Например, Услуги могут зависеть от Фабрик, которые зависят от Хранилищ, которые зависят от Сущностей.
Проект Impl - это то, что вы видите как оболочка лука "Инфраструктура" на диаграмме Палермо.Он находится на внешнем крае вместе с пользовательским интерфейсом и не содержит специфичных для предметной области знаний.Он знает, как отправлять электронную почту, сохранять / извлекать данные с помощью EF и т. Д. При желании вы можете иметь более 1 из них - например, 1 Impl для доступа к данным, 1 Impl для работы с почтой и т. Д.
MVC имеет Controllers и Views и концентрируется на пользовательском интерфейсе и потоке веб-приложений. Все, что требует специфичных для предметной области знаний, делегируется домену, а классы домена конструктор вводятся в контроллер. Это означает, что любые интерфейсы с внедрением конструктора в классах домена разрешаются автоматически контейнером IoC.
В заключение: программирование на основе интерфейсов, определенных в классах API и Domain, означает, что вы можете тестировать доменный проект отдельно от проекта MVC.