Обращали внимание, что почти никто и никогда не пишет в книгах и статьях о микросервисах о возможности повторного использования? Конечно, это не означает, что микросервисы нельзя повторно использовать, другое дело, что это уже будет другой микросервис в другом контексте с другими границами на уровне модели предметной области.
Стоит уточнить, что под повторным использованием (reusability) мы понимаем именно использование того же самого в другом контексте. Например, библиотека логирования. В любом контексте она остается библиотекой логирования, пусть мы ее используем в разных проектах, продуктах. Для микросервисов же важен контекст, они буквально создаются в рамках контекста и перенос микросервиса в другой контекст приводит к появлению нового микросервиса. Как только мы попытаемся сделать микросервис универсальным под два контекста — мы получили зависимость и попали в лапы затрат на координацию при внесении изменений, потеряли автономность в развитии.
Немного подробнее и в цифрах. Здесь X - знак умножения.
Ценность повторного использования мы можем выразить как:
(количество повторных использований) X
(стоимость разработки фичи) X
(фактор ценности при использовании повторно используемого компонента) —
(фактор стоимость разработки самого повторно используемого компонента) X
(стоимость разработки фичи)
Несколько пояснений:
фактор ценности при использовании повторно используемого компонента — процентная величина, 75% означает, что при использовании повторно используемого компонента требуется на 75% меньше усилий в сравнении с разработкой с нуля
фактор стоимость разработки самого повторно используемого компонента — процентная величина, повтрно используемый компонент реализовать — дороже, в зависимости от сложности может быть 150%, 300% и даже 500%.
Вынесем стоимость разработки фичи за скобки, получим:
Ценность повторного использования =
(стоимость разработки фичи) X (
(количество повторных использований) X (фактор ценности при использовании повторно используемого компонента) —
(фактор стоимости разработки самого повторно используемого компонента)
)
Как повысить ценность? Повышать количесство повторных использований, либо повышать фактор ценности при повторном использовании, либо снижать фактор стоимости разработки повторно используемого компонента. Все логично.
И более, чем логично, если это библиотека, которая не зависит от контекста использования.
Микросервисы не задумывались повторно используемыми. Они задумывались как сервисы в рамках границ контекста в модели бизнеса. Но если мы все же хотим повторно используемый микросервис?
1. Кол-во повторных использований будет равно единице. Иначе мы создаем зависимости и чем чаще используем повторно, чем выше координационная нагрузка, а значит тем выше (фактор стоимости разработки самого повторно используемого компонента)
2. Сама начальная стоимость повторно используемого микросервиса не определена, потому как мы на перед не знаем, в каких контекстах сможем его использовать повторно. Соответственно, либо всё, что можно будет обложено конфигурационными настройками (очень дорого), либо см. пункт 1.
Технические сервисы (не микросервисы, типа сервиса отправки писем, как sendmail с rest api - это не то же самое, что микросервис в его определении, такие сервисы можно использовать повторно, конечно, что мы и делаем - это generic или supporting домены).
Итого, делаем вывод, что для микросервисов в их первоначальном определении повторное использование не применимо из прагматичных соображений. Каждый микросервис создается под свои границы в конкретной модели предметной области бизнеса. Повторное использование микросервиса приводит к появлению нового микросервиса в новом контексте, развивающегося автономно от изначального микросервиса.
Готов подискутировать в комментариях.
Стоит уточнить, что под повторным использованием (reusability) мы понимаем именно использование того же самого в другом контексте. Например, библиотека логирования. В любом контексте она остается библиотекой логирования, пусть мы ее используем в разных проектах, продуктах. Для микросервисов же важен контекст, они буквально создаются в рамках контекста и перенос микросервиса в другой контекст приводит к появлению нового микросервиса. Как только мы попытаемся сделать микросервис универсальным под два контекста — мы получили зависимость и попали в лапы затрат на координацию при внесении изменений, потеряли автономность в развитии.
Немного подробнее и в цифрах. Здесь X - знак умножения.
Ценность повторного использования мы можем выразить как:
(количество повторных использований) X
(стоимость разработки фичи) X
(фактор ценности при использовании повторно используемого компонента) —
(фактор стоимость разработки самого повторно используемого компонента) X
(стоимость разработки фичи)
Несколько пояснений:
фактор ценности при использовании повторно используемого компонента — процентная величина, 75% означает, что при использовании повторно используемого компонента требуется на 75% меньше усилий в сравнении с разработкой с нуля
фактор стоимость разработки самого повторно используемого компонента — процентная величина, повтрно используемый компонент реализовать — дороже, в зависимости от сложности может быть 150%, 300% и даже 500%.
Вынесем стоимость разработки фичи за скобки, получим:
Ценность повторного использования =
(стоимость разработки фичи) X (
(количество повторных использований) X (фактор ценности при использовании повторно используемого компонента) —
(фактор стоимости разработки самого повторно используемого компонента)
)
Как повысить ценность? Повышать количесство повторных использований, либо повышать фактор ценности при повторном использовании, либо снижать фактор стоимости разработки повторно используемого компонента. Все логично.
И более, чем логично, если это библиотека, которая не зависит от контекста использования.
Микросервисы не задумывались повторно используемыми. Они задумывались как сервисы в рамках границ контекста в модели бизнеса. Но если мы все же хотим повторно используемый микросервис?
1. Кол-во повторных использований будет равно единице. Иначе мы создаем зависимости и чем чаще используем повторно, чем выше координационная нагрузка, а значит тем выше (фактор стоимости разработки самого повторно используемого компонента)
2. Сама начальная стоимость повторно используемого микросервиса не определена, потому как мы на перед не знаем, в каких контекстах сможем его использовать повторно. Соответственно, либо всё, что можно будет обложено конфигурационными настройками (очень дорого), либо см. пункт 1.
Технические сервисы (не микросервисы, типа сервиса отправки писем, как sendmail с rest api - это не то же самое, что микросервис в его определении, такие сервисы можно использовать повторно, конечно, что мы и делаем - это generic или supporting домены).
Итого, делаем вывод, что для микросервисов в их первоначальном определении повторное использование не применимо из прагматичных соображений. Каждый микросервис создается под свои границы в конкретной модели предметной области бизнеса. Повторное использование микросервиса приводит к появлению нового микросервиса в новом контексте, развивающегося автономно от изначального микросервиса.
Готов подискутировать в комментариях.