Тип поддомена и стратегия решения

Обычно DDD воспринимают как высшую математику: всё логично, но непонятно, как применять на практике. Сегодня предлагаю свести теорию с практикой и посмотреть, как определение поддомена определяет стратегию решения.

На самом деле стратегия не в том, чтобы пилить систему на поддомены; и не в самом факте существования поддомена. Стратегия – в выборе проектных решений, исходя из типа поддомена.

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

Смотрим, как сориентироваться на местности, сделав три простых шага.

Во-первых, введём понятие типа поддомена:

  • Основной (core). Уникальная деятельность компании (не обязательно техническая), определяющая её конкурентные преимущества. Основной домен может не приносить прибыль, но служить основой для её привлечения. Как например, поиск Google служит основой для рекламы – Google Ads.
  • Универсальный (generic). Деятельность, которую все компании выполняют или должны выполнять одинаково: бухгалтерский учёт, платежи, аутентификация, авторизация, шифрование, мониторинг и т.п. Сюда относятся готовые, широко используемые и проверенные временем решения. Например, для бухучёта 1С, для мониторинга OpenTelemetry и т.д.
  • Вспомогательный (supporting). Поддерживающий слой для основного поддомена. Это то поле, где универсальные решения не подходят или неудобны для ведения бизнеса. Например, административный интерфейс для настройки или поддержки системы.

Во-вторых, определим их свойства:

  • Основной – сложный и изменчивый, т.к. иначе не будет конкурентного преимущества.
  • Универсальный – сложный и стабильный, т.к. иначе каждый бы делал своё решение.
  • Вспомогательный – простой и стабильный, но со специфической бизнес-логикой, т.к. иначе подойдёт универсальное решение.

В-третьих, выберем стратегию решения:

  • Основной – делаем самостоятельно, силами лучших кадров; используем передовые технологии и уникальные алгоритмы.
  • Универсальный – используем готовые, проверенные временем решения.
  • Вспомогательный – делаем самостоятельно, силами middle-специалистов.

Вот, собственно, и всё: определив, к какому типу поддомена относится задача, делаем вывод, как и какими ресурсами она должна быть реализована.

И в контексте этого стоит сразу расставить красные флаги:

  • Если решением задачи вспомогательного поддомена является сложная машинерия, то, скорей всего, вы упоролись и делаете что-то, что решает уже имеющееся универсальное решение или их комбинация. Тут лучше остановиться, подумать и сделать шаг назад.
  • Сложность основного поддомена не определяет сложность решения. Напротив, сложность должна сводиться к минимуму, например, путем декомпозиции поддомена на более мелкие и делегирования большей части работы готовым решениям.
  • Ничего не стоит на месте. Типы поддоменов могут меняться, и это определяется деятельностью компании. Основной поддомен может стать вспомогательным для других; вспомогательный может трансформироваться в универсальное решение, которое начнёт приносить прибыль и станет основным для бизнеса; вспомогательные решения могут/должны заменяться универсальными.

Надеюсь, что этот простой приём поможет расходовать ресурсы более продуктивно.



Понравилась статья?

Посмею напомнить, что у меня есть Telegram-канал Архитектоника в ИТ, где я публикую материал на похожие темы примерно раз в неделю. Подписчики меня мотивируют, но ещё больше мотивируют живые дискуссии, ведь именно в них рождается истина. Поэтому подписывайтесь на канал и будем оставаться на связи! ;-)

Статьи из той же категории: