Много раз я видел, как на просьбу "показать архитектуру" (что бы это ни значило), присылают картинки типа тех, что приведены в иллюстрации 1 и 2. Эти я взял из интернетов и других источников, это реальный мир.
Сможете себе ответить, что тут не так? Если вы считаете, что всё корректно, то вам будет интересно, читайте далее внимательно.
Вообще это частая ситуация, когда под архитектурой мыслится некоторое модульное устройство системы (один из вьюпойнтов) со связями между ними.
Давайте вообразим гипотетическое устройство вымышленной системы, которую я только что сконструировал. Пусть на ней будут блоки "колотилка", "молотилка", модуль плющения и набор сепулек, как-то связанный с ними.
Вам понятно, что может делать система? Наверное, не очень. Но почему-то, когда на схеме изображается "БД", "сервер приложений", "модули API для связи", принято считать, что понятно. Я сейчас расскажу, где собака порылась - пропускается (вернее, держится "в голове") этап функционального анализа и синтеза. Архитектор-конструктор это всё "и так помнит": смотрит на модуль авторизации, понимает, что это функции авторизации, управления доступом и т.п.; смотрит на "сервис DbSrv", понимает, что это некоторая "функция общения с базой". Да и в целом тенденция такова, что один компонент (в терминах группы выполняемых функций) стараются реализовать при помощи одного модуля в структуре. А то и несколько функций на один модуль навешиваются.
Проблемы начинаются, когда система становится такого размера, что функции начинают совместно выполняться несколькими модулями в процессе их взаимодействия. А такое возникает неизбежно, потому что эмержентность это естественное свойство любой системы.
Понятно, в чём проблема? Проблема НАСТОЛЬКО частая, что ее можно в учебники вносить: структура системы бежит впереди функционального разбиения.
Не делайте так 🙂 Начинайте с функционального анализа и синтеза. Самый простой якорь - схема user stories: каждая story должна быть точно помаплена на части (даже не компоненты) системы, прицеплена к функциям системы (даже не IT-системы, а бизнеса), и иметь понятное описание, какой рабочий продукт в процессе исполнения этой story генерируется. А уже эти функции должны опереться на приложения и модули и быть поддержаны структурой. Потому что - не забывайте - в первую очередь надо сделать довольными стейкхолдеров. Они довольны, когда все их требования и ожидания находят отражение в системе.
Сможете себе ответить, что тут не так? Если вы считаете, что всё корректно, то вам будет интересно, читайте далее внимательно.
Вообще это частая ситуация, когда под архитектурой мыслится некоторое модульное устройство системы (один из вьюпойнтов) со связями между ними.
Давайте вообразим гипотетическое устройство вымышленной системы, которую я только что сконструировал. Пусть на ней будут блоки "колотилка", "молотилка", модуль плющения и набор сепулек, как-то связанный с ними.
Вам понятно, что может делать система? Наверное, не очень. Но почему-то, когда на схеме изображается "БД", "сервер приложений", "модули API для связи", принято считать, что понятно. Я сейчас расскажу, где собака порылась - пропускается (вернее, держится "в голове") этап функционального анализа и синтеза. Архитектор-конструктор это всё "и так помнит": смотрит на модуль авторизации, понимает, что это функции авторизации, управления доступом и т.п.; смотрит на "сервис DbSrv", понимает, что это некоторая "функция общения с базой". Да и в целом тенденция такова, что один компонент (в терминах группы выполняемых функций) стараются реализовать при помощи одного модуля в структуре. А то и несколько функций на один модуль навешиваются.
Проблемы начинаются, когда система становится такого размера, что функции начинают совместно выполняться несколькими модулями в процессе их взаимодействия. А такое возникает неизбежно, потому что эмержентность это естественное свойство любой системы.
Понятно, в чём проблема? Проблема НАСТОЛЬКО частая, что ее можно в учебники вносить: структура системы бежит впереди функционального разбиения.
Не делайте так 🙂 Начинайте с функционального анализа и синтеза. Самый простой якорь - схема user stories: каждая story должна быть точно помаплена на части (даже не компоненты) системы, прицеплена к функциям системы (даже не IT-системы, а бизнеса), и иметь понятное описание, какой рабочий продукт в процессе исполнения этой story генерируется. А уже эти функции должны опереться на приложения и модули и быть поддержаны структурой. Потому что - не забывайте - в первую очередь надо сделать довольными стейкхолдеров. Они довольны, когда все их требования и ожидания находят отражение в системе.