Представьте, что вы смотрите на чертежи здания.  Этот документ подготовленный архитектором, рассказывает вам о планах по строительству. Что рассказывают эти планы вам?

Если эти планы предназначены для семейного дома, то скорее всего вы увидите парадный вход, вход, фойе, ведущее в гостиную и возможно в столовую. На небольшом расстоянии от столовой скорее всего будет находится кухня. Возможно рядом с кухней будет зона обеденного уголка, а рядом с ней - семейная комната. Когда вы посмотрите на эти планы, у вас не останется сомнений, что перед вам дом.  Эта архитектура кричит вам что это: Дом

Или если вы смотрите на архитектуру библиотеки, ты скорее всего увидите там: парадный вход, зону регистрации, читальный зал, маленький конференц-зал, и галерею с книгами. Эта архитектура будет кричать вам «Это Библиотека»

И так, что кричит архитектура вашего приложения? Когда вы смотрите на самый верхний уровень директории, и на файлы верхнего уровня; они кричат вам: «Система здравоохранения», «Система бух учета», «Система управления запасами»? Или они кричат «Rails», «Spring/Hibernate», «ASP»?

Тема архитектуры

Вернемся назад и прочитаем книгу «Ivar Jacobson’s» про архитектуру ПО: Объектно-ориентированная разработка. Обратите внимание на подзаголовок книги «Использование системно-ориентированного подхода» (A use case driven approach). В этой книге Ivar обращает внимание, что архитектура ПО это структура, которая помогает использовать систему, иначе говоря - архитектура показывает сценарии того как использовать эту систему. Также как план дома или библиотеки кричит о вариантах использования этого здания, так же и ваша архитектура должна кричат о том, как использовать ваше приложение.

Архитектура не является (и недолжна) описывать Фреймворк. Архитектура не должна поставляться Фреймворком. Фреймворки - это инструменты для использования, а не архитектура, которой нужно соответствовать. Если ваша архитектура основана на Фреймворках, то она не может быть основана на ваших сценариях использования (use-cases).

Цель Архитектуры

Причина, по которой хорошие архитектуры сосредоточены вокруг сценариев использования (use-cases), заключается в том, что архитекторы могут безопасно описывать структуры, которые поддерживают эти сценарии использования, не принимая на себя обязательства в отношении Фреймворков, инструментов и среды. Опять же, рассмотрим план дома.  Первая забота архитектора - убедиться в том, что дом пригоден для использования, а не в том, чтобы дом был сделан из кирпича. Конечно, архитектор старается, чтобы домовладелец мог принять решение о выборе кирпича, камня или кедра позже, после того, как планы обеспечат выполнение условий использования.

Хорошая архитектура программного обеспечения позволяет откладывать решения о Фреймворках, базах данных, веб-серверах и других вопросах, и инструментах, связанных с окружающей средой. Хорошая архитектура позволяет не принимать решение о выборе Rails, или Spring, или Hibernate, или Tomcat, или MySql до тех пор, пока проект не будет завершен. Хорошая архитектура позволяет легко изменить свое мнение и по поводу этих решений. Хорошая архитектура делает акцент на сценариях использования и отделяет их от периферийных проблем.

Но что насчет веба?

Что есть веб архитектура? Диктует ли тот факт, что ваша система поставляется через Интернет, архитектуру вашей системы? Конечно же, нет! Веб - это механизм доставки, и архитектура вашего приложения должна относиться к нему как к таковому. Тот факт, что ваше приложение поставляется через Интернет, является деталью и не должно доминировать в структуре вашей системы. Действительно, тот факт, что ваше приложение поставляется через веб, - это то, что вы должны отложить. Архитектура вашей системы должна быть как можно менее осведомлена о том, как приложение будет поставляться. Вы должны быть в состоянии предоставить его как консольное приложение, или веб-приложение, или приложение толстого клиента, или даже приложение веб-сервиса без излишнего усложнения или изменения фундаментальной архитектуры.

Фреймворки - это инструменты, а не образ жизни.

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

Посмотрите на каждый фреймворк придирчивым взглядом. Смотрите на них скептически. Да, это может помочь, но какой ценой. Как я должен его использовать и как я должен от него защищаться. Как я могу сохранить акцент моей архитектуры на сценарии использования? Как я могу предотвратить поглощение архитектуры фреймворком.

Тестируемые архитектуры

Если архитектура вашей системы основана на сценариях использования, и если вы держите свои фреймворки на расстоянии вытянутой руки. Тогда вы должны иметь возможность тестировать все эти сценарии использования без каких-либо фреймворков. Вам не нужен работающий веб-сервер для запуска тестов. Для выполнения тестов не должна быть подключена база данных. Ваши бизнес-объекты должны быть простыми старыми объектами, которые не зависят от фреймворков, баз данных или других сложностей. Ваши объекты сценариев использования должны координировать ваши бизнес-объекты. И все они вместе должны быть тестируемы на месте, без каких-либо сложностей, связанных с фреймворками.

Заключение

Ваши архитектуры должны рассказывать читателям о системе, а не о фреймворках, которые вы использовали в своей системе. Если вы создаете систему здравоохранения, то когда новые программисты смотрят на репозиторий исходных текстов, их первым впечатлением должно быть: «О, это система здравоохранения». Эти новые программисты должны быть в состоянии изучить все сценарии использования системы и все еще не знать, как эта система поставляется. Они могут прийти к вам и сказать: «Мы видим некоторые вещи, которые выглядят как модели, но где же представления и контроллеры», а вы должны сказать: «О, это детали, которые не должны вас волновать в данный момент, мы покажем их вам позже».