Телеграмм чат группы itarchitect страница 2326

15:46пожаловаться #1

GK

23:16пожаловаться #2

GK

Тут Ньюман цитирует этот чатик. When I talk about the monolith ..., I am primarily referring to a unit of deployment. When all functionality in a system had to be deployed together, we consider it a monolith.

Together, на мой взгляд, не обязательно single unit of deployment. Посмотрим, что он об этом дальше в книге.

Maxim Smirnov in Архитектура ИТ-решений

23:23пожаловаться #3

MS

Gennadiy Kruglov

Тут Ньюман цитирует этот чатик. When I talk about the monolith ..., I am primarily referring to a unit of deployment. When all functionality in a system had to be deployed together, we consider it a monolith.

Together, на мой взгляд, не обязательно single unit of deployment. Посмотрим, что он об этом дальше в книге.

Драматургия заставляет в следующей главе появиться multi-processes monolith :-))

23:25пожаловаться #4

GK

Maxim Smirnov

Драматургия заставляет в следующей главе появиться multi-processes monolith :-))

Специально не стал заглядывать вперёд:) волнуюсь:)

23:27пожаловаться #5

GK

Смешно, Ньюман рассказал историю появления термина Microservice. Сначала был вариант Micro-App. Думаю, к несчастью, ребята из ThoughtWork фатально ошиблись. Потому что Micro-App - это верный вариант:) Все их объяснения, что такое Microservice выглядят как оправдание.

23:38пожаловаться #6

2019 December 02

AS

Gennadiy Kruglov

Смешно, Ньюман рассказал историю появления термина Microservice. Сначала был вариант Micro-App. Думаю, к несчастью, ребята из ThoughtWork фатально ошиблись. Потому что Micro-App - это верный вариант:) Все их объяснения, что такое Microservice выглядят как оправдание.

Геннадий, а что значит верный вариант? Если под micro-app понимается модульное приложение с возможностью относительно независимого развертывания модулей, то это все равно остаётся монолитом. Требование автономности не выполняется, сохраняется сильный coupling.

00:58пожаловаться #7

GK

Геннадий, а что значит верный вариант? Если под micro-app понимается модульное приложение с возможностью относительно независимого развертывания модулей, то это все равно остаётся монолитом. Требование автономности не выполняется, сохраняется сильный coupling.

Micro-App может не быть монолитом, даже если у всех его сервисов единый владелец и жизненный цикл, то есть даже если они развёртывается вместе.

Сервисы могут иметь низкую связность.

01:03пожаловаться #8

PD

Геннадий, а что значит верный вариант? Если под micro-app понимается модульное приложение с возможностью относительно независимого развертывания модулей, то это все равно остаётся монолитом. Требование автономности не выполняется, сохраняется сильный coupling.

Если возможно независимое развертывание модулей - то откуда сильный coupling?

01:05пожаловаться #9

AS

Gennadiy Kruglov

Micro-App может не быть монолитом, даже если у всех его сервисов единый владелец и жизненный цикл, то есть даже если они развёртывается вместе.

Сервисы могут иметь низкую связность.

Для низкой связности нужно выделение bounded context.

Но переход к микросервисам существенно упрощается, так как модули, как правило, строятся вокруг субдоменов

01:05пожаловаться #10

AS

Если возможно независимое развертывание модулей - то откуда сильный coupling?

Зависимости общие, например 2 сервиса и одна бд

01:06пожаловаться #11

PD

А кто мешает выделять bounded context внутри приложения с модулями?

01:06пожаловаться #12

GK

А кто мешает выделять bounded context внутри приложения с модулями?

Именно

01:06пожаловаться #13

PD

Зависимости общие, например 2 сервиса и одна бд

Если они используют БД для документированного обмена данными, то это ровно та же связность, что через какой-нибудь REST-API или кафку.

01:07пожаловаться #14

AS

А кто мешает выделять bounded context внутри приложения с модулями?

Тогда оно постепенно превратится в набор микросервисов. Остаётся только репозитории разнести.

01:08пожаловаться #15

PD

А зачем делать плохо там, где хорошо? В разнесение репозитариев больше вреда, чем пользы.

01:09пожаловаться #16

AS

А зачем делать плохо там, где хорошо? В разнесение репозитариев больше вреда, чем пользы.

Разрабатывать сложно в одном репозитории, много конфликтов при частом коммите

01:11пожаловаться #17

PD

Микросервисы вполне могут быть внутри одного приложения на каком-нибудь OSGi.
А уж разделение контекстов применяли вообще с древних времён, модульность ещё до ООП появилась

01:11пожаловаться #18

PD

Разрабатывать сложно в одном репозитории, много конфликтов при частом коммите

Это что-то не так с разработкой значит. Откуда конфликты-то?

01:11пожаловаться #19

AS

Микросервисы вполне могут быть внутри одного приложения на каком-нибудь OSGi.
А уж разделение контекстов применяли вообще с древних времён, модульность ещё до ООП появилась

Простите, а вы знаете в чем разница между понятием subdomain и bounded context?