MICROSERVICES_ARCH Telegram 171
Обращали внимание, что почти никто и никогда не пишет в книгах и статьях о микросервисах о возможности повторного использования? Конечно, это не означает, что микросервисы нельзя повторно использовать, другое дело, что это уже будет другой микросервис в другом контексте с другими границами на уровне модели предметной области.

Стоит уточнить, что под повторным использованием (reusability) мы понимаем именно использование того же самого в другом контексте. Например, библиотека логирования. В любом контексте она остается библиотекой логирования, пусть мы ее используем в разных проектах, продуктах. Для микросервисов же важен контекст, они буквально создаются в рамках контекста и перенос микросервиса в другой контекст приводит к появлению нового микросервиса. Как только мы попытаемся сделать микросервис универсальным под два контекста — мы получили зависимость и попали в лапы затрат на координацию при внесении изменений, потеряли автономность в развитии.

Немного подробнее и в цифрах. Здесь X - знак умножения.

Ценность повторного использования мы можем выразить как:
(количество повторных использований) X
(стоимость разработки фичи) X
(фактор ценности при использовании повторно используемого компонента)
(фактор стоимость разработки самого повторно используемого компонента) X
(стоимость разработки фичи)

Несколько пояснений:
фактор ценности при использовании повторно используемого компонента — процентная величина, 75% означает, что при использовании повторно используемого компонента требуется на 75% меньше усилий в сравнении с разработкой с нуля

фактор стоимость разработки самого повторно используемого компонента — процентная величина, повтрно используемый компонент реализовать — дороже, в зависимости от сложности может быть 150%, 300% и даже 500%.

Вынесем стоимость разработки фичи за скобки, получим:

Ценность повторного использования =
(стоимость разработки фичи) X (
(количество повторных использований) X (фактор ценности при использовании повторно используемого компонента)
(фактор стоимости разработки самого повторно используемого компонента)
)

Как повысить ценность? Повышать количесство повторных использований, либо повышать фактор ценности при повторном использовании, либо снижать фактор стоимости разработки повторно используемого компонента. Все логично.
И более, чем логично, если это библиотека, которая не зависит от контекста использования.

Микросервисы не задумывались повторно используемыми. Они задумывались как сервисы в рамках границ контекста в модели бизнеса. Но если мы все же хотим повторно используемый микросервис?

1. Кол-во повторных использований будет равно единице. Иначе мы создаем зависимости и чем чаще используем повторно, чем выше координационная нагрузка, а значит тем выше (фактор стоимости разработки самого повторно используемого компонента)
2. Сама начальная стоимость повторно используемого микросервиса не определена, потому как мы на перед не знаем, в каких контекстах сможем его использовать повторно. Соответственно, либо всё, что можно будет обложено конфигурационными настройками (очень дорого), либо см. пункт 1.
Технические сервисы (не микросервисы, типа сервиса отправки писем, как sendmail с rest api - это не то же самое, что микросервис в его определении, такие сервисы можно использовать повторно, конечно, что мы и делаем - это generic или supporting домены).

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

Готов подискутировать в комментариях.



tgoop.com/microservices_arch/171
Create:
Last Update:

Обращали внимание, что почти никто и никогда не пишет в книгах и статьях о микросервисах о возможности повторного использования? Конечно, это не означает, что микросервисы нельзя повторно использовать, другое дело, что это уже будет другой микросервис в другом контексте с другими границами на уровне модели предметной области.

Стоит уточнить, что под повторным использованием (reusability) мы понимаем именно использование того же самого в другом контексте. Например, библиотека логирования. В любом контексте она остается библиотекой логирования, пусть мы ее используем в разных проектах, продуктах. Для микросервисов же важен контекст, они буквально создаются в рамках контекста и перенос микросервиса в другой контекст приводит к появлению нового микросервиса. Как только мы попытаемся сделать микросервис универсальным под два контекста — мы получили зависимость и попали в лапы затрат на координацию при внесении изменений, потеряли автономность в развитии.

Немного подробнее и в цифрах. Здесь X - знак умножения.

Ценность повторного использования мы можем выразить как:
(количество повторных использований) X
(стоимость разработки фичи) X
(фактор ценности при использовании повторно используемого компонента)
(фактор стоимость разработки самого повторно используемого компонента) X
(стоимость разработки фичи)

Несколько пояснений:
фактор ценности при использовании повторно используемого компонента — процентная величина, 75% означает, что при использовании повторно используемого компонента требуется на 75% меньше усилий в сравнении с разработкой с нуля

фактор стоимость разработки самого повторно используемого компонента — процентная величина, повтрно используемый компонент реализовать — дороже, в зависимости от сложности может быть 150%, 300% и даже 500%.

Вынесем стоимость разработки фичи за скобки, получим:

Ценность повторного использования =
(стоимость разработки фичи) X (
(количество повторных использований) X (фактор ценности при использовании повторно используемого компонента)
(фактор стоимости разработки самого повторно используемого компонента)
)

Как повысить ценность? Повышать количесство повторных использований, либо повышать фактор ценности при повторном использовании, либо снижать фактор стоимости разработки повторно используемого компонента. Все логично.
И более, чем логично, если это библиотека, которая не зависит от контекста использования.

Микросервисы не задумывались повторно используемыми. Они задумывались как сервисы в рамках границ контекста в модели бизнеса. Но если мы все же хотим повторно используемый микросервис?

1. Кол-во повторных использований будет равно единице. Иначе мы создаем зависимости и чем чаще используем повторно, чем выше координационная нагрузка, а значит тем выше (фактор стоимости разработки самого повторно используемого компонента)
2. Сама начальная стоимость повторно используемого микросервиса не определена, потому как мы на перед не знаем, в каких контекстах сможем его использовать повторно. Соответственно, либо всё, что можно будет обложено конфигурационными настройками (очень дорого), либо см. пункт 1.
Технические сервисы (не микросервисы, типа сервиса отправки писем, как sendmail с rest api - это не то же самое, что микросервис в его определении, такие сервисы можно использовать повторно, конечно, что мы и делаем - это generic или supporting домены).

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

Готов подискутировать в комментариях.

BY Микросервисы / распределенные системы


Share with your friend now:
tgoop.com/microservices_arch/171

View MORE
Open in Telegram


Telegram News

Date: |

How to Create a Private or Public Channel on Telegram? How to Create a Private or Public Channel on Telegram? The creator of the channel becomes its administrator by default. If you need help managing your channel, you can add more administrators from your subscriber base. You can provide each admin with limited or full rights to manage the channel. For example, you can allow an administrator to publish and edit content while withholding the right to add new subscribers. The channel also called on people to turn out for illegal assemblies and listed the things that participants should bring along with them, showing prior planning was in the works for riots. The messages also incited people to hurl toxic gas bombs at police and MTR stations, he added. Co-founder of NFT renting protocol Rentable World emiliano.eth shared the group Tuesday morning on Twitter, calling out the "degenerate" community, or crypto obsessives that engage in high-risk trading.
from us


Telegram Микросервисы / распределенные системы
FROM American