Блог компании

Илья Гарах Партнер, тех. директор.

Думаю, нет смысла уходить в академические дебри и рассказывать, что такое архитектура приложений. Все прекрасно понимают такие требования как легкая поддержка, масштабируемость, повторное использование и т.п., а так же каждый разработчик мучился от того, что его изменения ломают другие части системы, и это только малая доля сложностей на пути к идеальной архитектуре. Можно ли достичь идеальной архитектуры? — я думаю, на эту тему будет отдельный пост.

Итак, одним из распространённых подходов является разделение вашей системы на слои (Layers). Слои располагаются друг над другом и содержат логически схожие компоненты с примерно одинаковым уровнем абстракции. Основная идея концепции заключается в том, что нижележащие слои максимально не зависят от вышележащих. Таким образом, компоненты из N-ого слоя могут взаимодействовать только с компонентами своего слоя, а так же с компонентами более низких слоев.
К слову, если ваша архитектура позволяет N-слойным компонентам взаимодействовать только со своим слоем и слоем (N+1), то у вас реализовано строгое разделение на слои. 

Если же N-ый слой может взаимодействовать с N+1, N+2 и другими слоями, то мы получаем гибкое разделение на слои.
Любое гибкое разделение можно привести к строгому, пробрасывая взаимодействие через промежуточные слои. Подобное пробрасывание взаимодействий может существенно расширить слои, по сути, бесполезными обертками, методами и т.п., но и с другой стороны создаст более строгий уровень изоляции и зависимостей. Какого метода придерживаться — это один из компромиссов, который должен решить системный архитектор.

Так же, стоить отметить, что более строгое разделение на слои упрощает функциональное и юнит тестирование, так как покрытие тестами верхних слоев, частично или полностью затронет все нижележащие слои (в случае строгого разделения), что позволит быстрее достичь необходимого уровня покрытия. Кстати, в случае TDD, тесты пишутся до создания непосредственно кода, но совместно с проектированием архитектуры. На ряде своих проектов мы начали внедрять такой подход и действительно ощутили явные преимущества, более четкое и полное понимание происходящего, а так же избежали многих логических ошибок. При проектировании мы покрываем примерно от 10 до 30 процентов кода, этого хватает, чтоб сделать систему достаточно устойчивой к изменениям, а так же не тратить много времени на поддержку тестов.

Для детализации того, что должно находиться в слоях, и как они должны взаимодействовать, необходимо понять цели приложения, его потенциальную сложность и перспективы развития.
В следующем посте мы поговорим о быстрой разработке приложений, ориентации на данные — методах подходящих для не очень сложных систем, а так же о разработке на основе доменов, ориентации на сущность задач.