"Примирение" программной архитектуры и кода

Многие команды разработчиков ПО структурируют код уровень за уровнем. Другими словами, если открыть код, вы увидите пакет для классов предметной области, один для пользовательского интерфейса, один для "бизнес-сервисов", для доступа к данным, другой - для точек интеграции и т.д.

Этому есть простое объяснение. Нам известно, что делить на уровни - хорошо и многие учебники приводят такой подход в качестве способа структурирования кода. Если погуглить, например, учебные пособия по Spring или ASP.NET MVC, то это показано в их примерах. Я провел в Лондоне более 10 лет, создавая программные системы на Java, и тоже часто использовал пакетирование для проектов, над которыми работал.   

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

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

Например, одну "часть" компонента можно найти в пакете "сервисов", а остальную - в пакете "доступа к данным". Для этого код на нижних уровнях (к примеру, пакета "доступа к данным") обладает открытой видимостью, то есть, его можно вызвать из любого уровня архитектуры.   

Итак, к чему это?

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

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

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

Как и повсюду в ИТ-индустрии, здесь существует золотая середина. Ничто не мешает вам создавать монолитную систему, структура которой позволит вам позже перейти на микросервисную архитектуру.

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

Возможно, если попытаться объединить эти две сферы, то команды перестанет раздражать фраза "архитектурный рефакторинг".

источник