PD
Разве? Мы это в тимлидском чатике обсуждали. Но с моей точки зрения service-per-team скорее антипаттерн. Приводит к силосам и постоянным узким местам при реализации фич.
Size: a a a
2019 November 19
GK
Всё глубже
GK
У Ромы более чёткое понимание, чем у Ричардсона. Точнее мы понимаем более менее одинаково, но Рома своё мнение публично озвучил
GK
А Ричардсон на самом деле признал, что декомпозиция микросервисов не только по DDD и Business Capabilities
GK
Точнее, декомпозиция сервисов;)
GK
Ричардсон на самом деле рассуждает не совсем как архитектор, как хороший софтварь инженер. Он не говорит о стейкхолдерах.
GK
A team should be small, e.g. 5-9 people
A team should be autonomous and loosely coupled
A team should be autonomous and loosely coupled
PD
Ну вот фигня это - про автономность. Не получается кроме как для интерфейсных задач.
PD
А где у Ромы было, я пропустил, кажется.
GK
Доклад на SECR
GK
A team should ideally own just one service since that’s sufficient to ensure team autonomy and loose coupling and each additional service adds complexity and overhead. A team should only deploy its code as multiple services if it solves a tangible problem, such as significantly reducing lead time or improving scalability or fault tolerance.
PD
О, доклада не слышал. Видео уже есть?
GK
В том и фишка. Не получается один к одному. Поэтому название паттерна не корректное.
GK
Но главное, выравнивание с бизнесом происходит через стейкхолдеров от бизнеса
PD
Там две фигни: 1. не получатеся сделать самостоятельные команды в сложном окружении. Нужно много экспертизы извне.
2. Владение кодом делает команду узким местом для проекта.
2. Владение кодом делает команду узким местом для проекта.
PD
Но главное, выравнивание с бизнесом происходит через стейкхолдеров от бизнеса
А тут не понял, как это связано.
GK
Мне нужно подумать как хорошо объяснить
RT
Крис Ричардсон сегодня написал
выглядит как возврат в монолиты, ведь монолит это и есть service per team)
У нас есть свои особенности:
1) команда обычно владеет больше чем одним сервисом
2) набор команд меняется, сервисы и бизнес-процессы передаются во владение другим командам
и все-таки я хотел сказать что границы сервисов определяются по прикладным доменам (задачам), а также и команды формируются по прикладным доменам, так, чтобы сложность структурировалась по продуктам/доменам, команды формировались по продуктам/доменам, одним сервисом владела одна команда
У нас есть свои особенности:
1) команда обычно владеет больше чем одним сервисом
2) набор команд меняется, сервисы и бизнес-процессы передаются во владение другим командам
и все-таки я хотел сказать что границы сервисов определяются по прикладным доменам (задачам), а также и команды формируются по прикладным доменам, так, чтобы сложность структурировалась по продуктам/доменам, команды формировались по продуктам/доменам, одним сервисом владела одна команда
KТ
выглядит как возврат в монолиты, ведь монолит это и есть service per team)
У нас есть свои особенности:
1) команда обычно владеет больше чем одним сервисом
2) набор команд меняется, сервисы и бизнес-процессы передаются во владение другим командам
и все-таки я хотел сказать что границы сервисов определяются по прикладным доменам (задачам), а также и команды формируются по прикладным доменам, так, чтобы сложность структурировалась по продуктам/доменам, команды формировались по продуктам/доменам, одним сервисом владела одна команда
У нас есть свои особенности:
1) команда обычно владеет больше чем одним сервисом
2) набор команд меняется, сервисы и бизнес-процессы передаются во владение другим командам
и все-таки я хотел сказать что границы сервисов определяются по прикладным доменам (задачам), а также и команды формируются по прикладным доменам, так, чтобы сложность структурировалась по продуктам/доменам, команды формировались по продуктам/доменам, одним сервисом владела одна команда
А можно поподробнее 2 пункт. Начинают одни, завершают вторые?