Проектирование информационных систем всегда сопряжено с растущей сложностью. Будь то сложностями моделируемых бизнес-процессов в реальной жизни, технической сложностью моделей не имеющих отражения в реальном мире, любая система, с ростом функциональности, непременно будет наращивать свою общую сложность.
Способ структурирования программных компонентов приложения, для управления и приручения сложности и называется Архитектурой Приложения.
Но что именно значит “управление и приручение сложности”? В первую очередь это способ достижения расширяемости системы: возможность добавлять, изменять программные компоненты непринуждённо, независимо друг от друга, таким образом, что вносимые изменения имеют минимальный эффект на другие компоненты системы. Расширямое приложение структурировано таким образом, что его компоненты имеют низкую связанность (low coupling). Так же надо сказать, что низкая связанность должна быть не только у компонентов приложения, а и у единиц её функционала, другими словами, должен соблюдаться SRP (ex: логика рассчета суммы чека не должна быть связана с выводом этой информации на консоль).
Достижение низкой связанности и соблюдения SRP имеет общий механизм реализации – декомпозицию. Но.. что декомпозировать? Хотя тут больше подойдёт вопрос “на что?”.
В большинстве ваших лабораторных имелся один проект с кодом, и логическими модулями в разрезе этого проекта являлись ваши типы. Архитектура приложений же, является более высокоуровневой концепцией, в её разрезе, логическими единицами являются модули, в контексте C# модули называются проектами.
Многослойные архитектуры являются не первой вариацией модульной декомпозиции приложений.
Одной из первых была концепция MVC, в дальнейшем получившая набор разновидностей, различающихся в основном способами взаимодействия между модулями, так что можно обозначить эту архитектуру как MVX.
Суть такого разбиения заключается в соблюдении SRP. Действительно, каждый из модулей имеет свою собственную причину для изменений.
Model - модуль содержащий бизнес логику. Причиной его изменений является изменения бизнес-правил или же юзкейсов системы.
View - модуль представления приложения. Может быть как GUI, CUI, API, что-то ответственное за определение способа взаимодействия внешнего мира с нашим приложением. Причиной его изменений являются как раз изменения этого способа.
Controller/Presenter/ViewModel - модуль, являющийся адаптером между модулями Model и View. Отвечает за передачу данных между ними. Его причиной изменения, соответсвенно, является изменения механизмов взаимодействия остальных модулей.
Несмотря на то, что такая декомпозиция сильно лучше объединения всего в одну кучу, она имеет явные недостатки. Внимательные слушатели заметили то, что я ничего не упомянул про Low Coupling, что понятно, ведь он тут явно нарушается. Любая из вариаций семейства MVX в том или ином виде имеет циклические зависимости и это приводит к тесной связи между модулями, что при достижении достаточной сложности, сделает поддержку приложения обременяющей и не эффективной.
Рост сложности информационных систем это естественный процесс. Он обусловлен ростом вычислительных мощностей, развитием инструментов разработки, в общем говоря, технологии становятся способны реализовывать всё больше и больше потребностей бизнеса.
Увеличение сложности ПО означает появление бОльшего количество движущихся частей в приложениях, для упрощения поддержи нужно уметь верно определять, декомпозировать и организовывать эти части.
Следующей вариацией рассмотрим трёхслойную архитектуру. Её целью было соблюдение низкой связанности модулей вдобавок с соблюдению SRP.
Так как мы начали рассматривать многослойные архитектуры, то термин модуль заменяется на термин слой, чтобы соответствовать общему неймингу.