Кодирование в монолите

По своему опыту я обнаружил, что монолиты веб-приложений очень часто встречаются во многих успешных компаниях. Возможно, этому есть много причин, но я обнаружил, что большинство компаний начинают и продолжают развивать свой минимально жизнеспособный продукт. Этот тип продукта обычно создается быстро, с использованием полнофункциональных веб-фреймворков, таких как Django, Laravel или даже фреймворка ASP.NET MVC. Затем разработчики продолжают строить на основе этого MVP по мере поступления запросов на новые функции — это во многом связано с поиском соответствия продукта рынку, что приводит к тому, что приложение иногда строится на шатком фундаменте… Итак, что же делать, если вы работаете с таким продуктом?

Перестраивать или продолжать величественный монолит?

Это почти похоже на видеоигру. Теперь, когда вы продвинулись в игре, перезапускаете ли вы своего персонажа и добавляете очки в те области, которые, как вы знаете, вам необходимы для достижения успеха (теперь, когда вы знаете, на что похожа игра), или вы продолжаете с того места, где остановились, и пытаетесь адаптировать приобретенные навыки, поскольку игра продолжает вести вас в неизведанные места?

Перестроиться:

Плюсы
  • Больше никакого устаревшего кода 😸.
  • Теперь вы можете использовать новейшие технологии 📡
  • Вы лучше понимаете бизнес, поэтому ваша архитектура будет значительно лучше благодаря преимуществу ретроспективы. 👀
  • В целом, лучший опыт разработки 🎉
  • Более высокая гибкость для адаптации к будущим изменениям бизнеса. Лучшая архитектура обеспечивает лучшую гибкость. ⚡️
Минусы
  • Ваши клиенты не собираются ждать, пока новая сборка будет завершена, они будут продолжать просить больше функций. Теперь у вас есть проблема — добавление функций в старое приложение во время создания нового. 😤
  • Внедрение новой системы багов 🐛. Несмотря на то, что в старой системе было много унаследованного мусора, в ней были годы исправления ошибок и тестирования. Эта перестройка не будет иметь такой возможности, что приведет к некоторой нестабильности новой системы.
  • Вопросы от заинтересованных сторон, спрашивающих вас — когда это будет сделано? 💀 Это самое сложное для прогнозирования. На то, чтобы добраться до старой системы, ушли годы — как оценить перестройку всей системы?

Продолжить? 🚌

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

Третий вариант? 🏗

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

app/
   Events/
      NotificationDelivered.php
   Mail/
      OrderSuccessfulEmail.php
      ItemShippedEmail.php
   Jobs/
      ProcessOrder.php
      ShipItems.php
   Actions/
      SubmitOrder.php
      ShipOrders.php
Вход в полноэкранный режим Выход из полноэкранного режима

В этом примере SubmitOrder.php отправляет задание ProcessOrder.php. Это задание затем доставит электронное письмо пользователю (OrderSuccessfulEmail.php), которое затем вызовет общее событие NotificationDelivered.php. Вы можете рассматривать эти 3 файла как часть более крупного «домена», например, «Orders». Некоторые из других файлов можно рассматривать как часть другого домена под названием «Shipping». Давайте рефакторим эти классы вокруг доменов.

app/
   Events/
      NotificationDelivered.php

domain/
   Orders/
      Mail/
         OrderSuccessfulEmail.php
      Jobs/
         ProcessOrder.php
      Actions/
         SubmitOrder.php
   Shipping/
      Mail/
         ItemShippedEmail.php
      Jobs/
         ShipItems.php
      Actions/
         ShipOrders.php
Вход в полноэкранный режим Выход из полноэкранного режима

Итак, что мы получаем в результате?

  1. Ваши домены четко определены в этих папках доменов.
  2. Все эти функции — это просто группы связанных функций домена.

Разделение этих доменов на собственные папки функций позволяет нам отделить эти домены в будущем. Например, вся функция Shipping может быть скопирована в собственный экземпляр Laravel и запущена отдельно как микросервис когда-нибудь 😵💫. Конечно, это не обязательно должно произойти сразу, но перевод вашего монолита на подобный шаблон позволит вам двигаться в правильном направлении, чтобы в будущем постепенно разрушать его 😸.

В моей нынешней компании мы придерживаемся именно такого подхода. Он позволяет нам откусывать куски от этого слона понемногу за раз. Это огромный вызов, учитывая, что мы одновременно растем как организация и внедряем новые процессы. Боли роста стартапа 😬.

Просто хотел поделиться своим опытом. Если вы работали с монолитами в прошлом, я буду рад услышать, как ваша компания смогла адаптироваться! Чем больше знаний мы сможем разделить, тем лучше ❤️.

Оцените статью
Procodings.ru
Добавить комментарий