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: |

So far, more than a dozen different members have contributed to the group, posting voice notes of themselves screaming, yelling, groaning, and wailing in various pitches and rhythms. Judge Hui described Ng as inciting others to “commit a massacre” with three posts teaching people to make “toxic chlorine gas bombs,” target police stations, police quarters and the city’s metro stations. This offence was “rather serious,” the court said. Don’t publish new content at nighttime. Since not all users disable notifications for the night, you risk inadvertently disturbing them. "Doxxing content is forbidden on Telegram and our moderators routinely remove such content from around the world," said a spokesman for the messaging app, Remi Vaughn. Today, we will address Telegram channels and how to use them for maximum benefit.
from us


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