Эволюция моделирования программного обеспечения: от объектов к микросервисам
Эволюция единиц проектирования программного обеспечения — от объектов (Object) к микросервисам (Microservice) — представляет собой не просто изменение способов написания кода. Это непрерывный поиск ответа на фундаментальный вопрос: как человеку эффективно управлять большими и сложными системами?
В этой статье мы рассмотрим этот процесс через аналогию с ростом небольшой стартап-компании до глобальной корпорации, отражая развитие технологий моделирования.
1. Эпоха OOAD: прямое взаимодействие увлечённых людей (объектно-ориентированный подход)
На раннем этапе OOAD (объектно-ориентированный анализ и проектирование) организация напоминала небольшую команду, где каждый участник чётко понимал свои роли и обязанности (R&R) и работал слаженно.
В этот период минимальной единицей программного обеспечения был объект, и все объекты существовали внутри одного контейнера — словно сотрудники, работающие в одном здании.
Участники команды напрямую общались друг с другом, обращаясь к коллегам, сидящим рядом. Они активно делились данными и функциональностью, что позволяло быстро принимать решения и действовать.
Однако, когда численность сотрудников превысила 100 человек, возник хаос. Руководству стало сложно понимать, кто обладает какими компетенциями, а кто бездействует. Пути коммуникации запутались, и затраты на взаимодействие начали снижать эффективность работы.
Когда слишком много отдельных единиц сосредоточено в одном физическом пространстве, даже небольшие изменения могли нарушить порядок всей системы, что приводило к неэффективности.
2. Эпоха CBD: внедрение отделов и специализация (компонентный подход)
Чтобы преодолеть эти ограничения, была внедрена концепция CBD (разработка на основе компонентов).
Появилось понятие отделов, объединяющих связанные объекты в единые блоки — компоненты. Были сформированы такие подразделения, как HR, финансы и разработка, с чёткими границами и внутренней иерархией.
Теперь руководству не нужно было управлять 100 сотрудниками напрямую — достаточно было контролировать около 10 руководителей отделов. Организация стала более структурированной, а каждый отдел начал развивать свою экспертизу, функционируя как переиспользуемый «компонент».
Тем не менее, проблема оставалась: взаимодействие между отделами по-прежнему требовало личных встреч — походов в другие офисы или проведения офлайн-совещаний.
Хотя структура была разделена, способ коммуникации всё ещё был привязан к физическому пространству главного офиса.
3. Эпоха SOA: онлайн-сети и появление сервисов (сервисно-ориентированный подход)
Когда численность организации достигла 200 человек, а задачи усложнились, неэффективность физического взаимодействия стала очевидной.
Это привело к внедрению SOA (сервисно-ориентированной архитектуры).
Каждому отделу был предоставлен стандартизированный способ коммуникации — своего рода «стандартный телефон» (RESTful API). Вся межотделовая коммуникация должна была происходить исключительно через эти стандартизированные интерфейсы.
Отделы превратились в сервисы, предоставляющие функциональность, доступную для внешнего вызова.
Теперь сотрудникам не нужно было физически посещать другие отделы. Они могли отправлять запросы через чётко определённые интерфейсы и получать результаты в реальном времени.
Однако и у этой модели была слабость: вся система по-прежнему зависела от единого главного офиса (одного контейнера).
Если центральная инфраструктура выходила из строя (например, из-за сбоя сервера или отключения электроэнергии), все сервисы останавливались одновременно. Это создавало серьёзную архитектурную уязвимость.
4. Эпоха MSA: независимые подразделения и полностью распределённые офисы (микросервисный подход)
Когда численность сотрудников превысила 300 человек, проблемы централизованной структуры стали критическими.
В результате была внедрена MSA (архитектура микросервисов).
Организация была разделена на независимые распределённые единицы, подобные отдельным филиалам или бизнес-подразделениям.
Каждая единица — теперь микросервис — функционирует как небольшая автономная компания со своей инфраструктурой, правилами и операционной независимостью.
Например:
- клиентов в Сеуле обслуживает офис в Каннаме
- региональных клиентов обслуживают локальные филиалы
Даже если один филиал сталкивается с проблемами (например, пожаром), остальные продолжают работать без перебоев.
Таким образом, произошла эволюция:
- от отдельных объектов (людей),
- к отделам (компонентам),
- к связанным сервисам (SOA),
- и, наконец, к полностью распределённой системе (MSA)
Этот процесс демонстрирует ключевой инженерный принцип: с ростом системы необходимо снижать связанность и повышать независимость.
С этой точки зрения MSA — это не просто тренд, а оптимальная архитектурная модель для выживания сложных систем.
5. Неизменная сущность: корень всей эволюции — это объект
Мы рассмотрели внешние изменения архитектуры — от объектов к компонентам, сервисам и микросервисам.
Несмотря на значительные изменения внешней структуры, её основа остаётся неизменной: объект (Object).
- компоненты — это наборы взаимодействующих объектов
- сервисы и микросервисы также состоят из взаимодействующих объектов
Эволюция архитектуры — это всего лишь изменение подходов к:
- агрегации (объединению объектов)
- инкапсуляции (разделению границ)
В своей основе всё по-прежнему сводится к взаимодействию объектов.
Ребекка Вирфс-Брок (Rebecca Wirfs-Brock) определила объект не просто как контейнер данных, а как активную сущность, выполняющую определённую роль в системе.
Она выделила следующие типы ролей объектов:
Типы ролей объектов
- Хранитель информации (Information Holder): хранит и предоставляет данные
- Структуризатор (Structurer): организует связи и структуру системы
- Поставщик услуг (Service Provider): выполняет задачи и вычисления
- Координатор (Coordinator): управляет взаимодействиями и потоками работы
- Контроллер (Controller): отслеживает изменения состояния и принимает решения
- Интерфейс (Interfacer): взаимодействует с внешними системами или пользователями
Внутри любого микросервиса такие объекты взаимодействуют, обеспечивая его функциональность.
Заключение
Проектирование качественного микросервиса — это, по сути, процесс правильного распределения ролей и ответственности между объектами и организации их взаимодействия.
Даже в распределённых системах именно отдельные элементы (объекты) создают реальную ценность — как сотрудники внутри компании.
Хотя архитектура развивается от OOAD к компонентам и микросервисам, её фундамент остаётся неизменным: объектное моделирование.
Когда мы чётко определяем ответственность объектов и грамотно проектируем их взаимодействие, мы можем создавать надёжные и масштабируемые системы — будь то компоненты, сервисы или микросервисы.
Независимо от изменений технологий, сущность моделирования программного обеспечения по-прежнему заключается в объекте.
doitsong