Я смотрю на Onion Architecture пирогом и я запутался ...Луковая архитектура: должен ли проект UI иметь доступ к слою домена?
клиент должен UI иметь доступ к Domain Model и Domain Services? Или только до Application Services и Core?
Если быть точным, я спрашиваю: должен ли проект UI ссылаться на проекты доменов?
Несомненно, я не верю, что есть хорошая причина, чтобы избежать слоя пользовательского интерфейса, чтобы знать и использовать объекты домена. Очевидно, что если вы это сделаете, вы связываете UI Layer с Bussines Layer, но в конце концов, не будет ли UI-слой зависеть от бизнеса?
С другой стороны, противоположное нежелательно, это не хорошая практика для того, чтобы подключить бизнес к UI Layer. Что делать, если вы хотите, чтобы несколько слоев пользовательского интерфейса обращались к тем же бизнес-группам? В этом-то и дело.
Но имейте в виду, что нет золотого молотка. Не ищите окончательных правил о разработке программного обеспечения, но изучите принципы SOLID, это достойно.
Я знаю, что противоположность нежелательна. Но я подумал (на секунду), что все из домена, которое используется в клиенте UI, должно быть перенесено на уровень ядра –
. Обычно использование объектов домена в качестве слоя обхода, но это не означает, что вы должны всегда использовать его в этом случае. – malaguna
Да, но только объекты типа «Типы» или «Перечисления». Когда у меня есть функция (скажем, метод в Entity Entity), я использую ее в Application Service и Application Service в пользовательском интерфейсе. –
Важнейшей концепцией архитектуры лука и аналогичных концепций является сохранение уровня домена независимым. Это достигается за счет ограничения зависимостей всегда указывать внутри диаграммы, которую вы опубликовали.
Ссылка на проект пользовательского интерфейса на домен не нарушает это правило.
Уровень пользовательского интерфейса должен просто отправлять команды на прикладной уровень для каждого варианта использования. Однако даже при таком четком разделении проблем вы можете включить некоторые объекты уровня домена в эти команды - самые простые примеры, которые приходят на ум, - это типы значений и перечисления.
Цитата из Robert C. Martin's blog о зависимостях:
Зависимость Правило
концентрические круги представляют различные области программного обеспечения. В общем, чем дальше вы идете, тем выше уровень программного обеспечения. Внешние круги - это механизмы. Внутренние круги - это политики.
Правило переопределения, которое делает эту работу архитектуры, - это правило зависимостей. В этом правиле говорится, что зависимости исходного кода могут указывать только внутрь. Ничто из внутреннего круга ничего не знает о чем-то во внешнем круге. В частности, имя того, что объявлено во внешнем круге, не должно упоминаться кодом внутри внутреннего круга. Это включает в себя функции, классы. переменные или любой другой названный программный объект.
Точно так же форматы данных, используемые во внешнем круге, не должны использоваться внутренним кругом, особенно если эти форматы генерируются каркасом во внешнем круге. Мы не хотим, чтобы во внешнем круге что-то влияло на внутренние круги.
Редактировать
В комментариях вы упоминаете движущихся объектов из слоя домена к ядру приложения. В onion architecture термин «ядро приложения» означает Domain model + Domain services + Application services. Это не отдельный слой.
Спасибо! Теперь, когда все имеет смысл –
Я предполагаю, что сервисы домена - это уровень репозитория. Теперь вопросы: как я могу позволить моему слою UI сохранять новый объект домена с помощью репозитория. Это нужно делать только с помощью служб приложений. Поскольку службы приложений проверяют модель домена и запускают некоторые другие правила до того, как этот объект домена будет сохранен в хранилище данных – Pragmatic
Ненавижу этот догмат. Я думаю, что ответ зависит от многих вещей. Я бы дал вам другой ответ, если бы вы писали веб-интерфейс, который общался с веб-службами REST. Вот откуда берутся анти-шаблоны, подобные слоям DTO, которые сохраняют «чистоту». – duffymo
Обычно вещи не должны иметь прямого доступа ни к чему, кроме их непосредственных соседей. Потому что результат может легко стать грязной сетью зависимостей. Но я не вижу, чтобы это нарушалось, пока вы получаете доступ к своим объектам домена через ядро приложений/ядро приложения. – zapl
Я говорю о таких вещах, как 'Enums' или другие' Entites'. Например, когда метод службы приложений принимает значение «Enum» в качестве параметра или возвращаемого объекта некоторого «Entity». В этом случае, следует ли перевести «Enum» или «Entity» в Core? –