Основная и видимая разница между n-уровневой и чистой архитектурой - PullRequest
1 голос
/ 28 июня 2019

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

Согласно документам MS для чистой архитектуры , луковичная диаграмма должна отличаться от n-уровневой архитектуры , которая имеет форму слоя.

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

AnЕще лучший пример моей причины моей неуверенности - этот блог .Это не связано с .NET, но архитектура должна быть технологически независимой.Насколько я понимаю, фактический путь процесса основан на уровнях и в точности эквивалентен n-уровневой версии (отличается только тем, как он нарисован, что не имеет значения).

Является ли основное различие между этими двумя типами архитектуры просто в том, как мы их используем, или есть реальное различие в коде или в структуре проекта (за исключением именования, конечно)?

1 Ответ

1 голос
/ 28 июня 2019

Насколько я понимаю, фактический путь процесса основан на уровнях и точно эквивалентен n-уровневой версии (отличается только тем, как он нарисован, что не имеет значения).

Да, верно.

Является ли основное различие между этими двумя типами архитектуры просто в том, как мы их используем, или есть реальное различие в коде или в структуре проекта (за исключением наименования, конечно)?

Разница в том, что код знает, имеет ссылки на него, зависит от другого кода.

В N-Tier бизнес-логике необходимо знать API уровня инфраструктуры. Все зависимости указывают вниз.

В чистой архитектуре / луковой архитектуре и т. Д. Уровень инфраструктуры знает об API уровня домена. Все зависимости указывают внутрь .

Чистая архитектура ставит бизнес-логику и модель приложения в центр приложения. Вместо того, чтобы бизнес-логика зависела от доступа к данным или других проблем инфраструктуры, эта зависимость инвертируется: инфраструктура и детали реализации зависят от Application Core.

Этот стиль часто сопровождается использованием Composition Root , который отвечает за соединение компонентов, которые в конечном итоге будут выполнять работу.

Вы говорите, что в луковой версии нет слоя бизнес-логики? То есть что он запекается в ядре приложения?

Обычно под бизнес-логикой понимается лук. Например, Роберт Мартин предлагает

enter image description here

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

...