Size: a a a

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

2019 November 19

PD

Phil Delgyado in Архитектура ИТ-решений
Разве? Мы это в тимлидском чатике обсуждали. Но с моей точки зрения service-per-team скорее антипаттерн. Приводит к силосам и постоянным узким местам при реализации фич.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Всё глубже
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
У Ромы более чёткое понимание, чем у Ричардсона. Точнее мы понимаем более менее одинаково, но Рома своё мнение публично озвучил
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
А Ричардсон на самом деле признал, что декомпозиция микросервисов не только по DDD и Business Capabilities
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Точнее, декомпозиция сервисов;)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ричардсон на самом деле рассуждает не совсем как архитектор, как хороший софтварь инженер. Он не говорит о стейкхолдерах.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
A team should be small, e.g. 5-9 people

A team should be autonomous and loosely coupled
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
🙂
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну вот фигня это - про автономность. Не получается кроме как для интерфейсных задач.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А где у Ромы было, я пропустил, кажется.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Доклад на SECR
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
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

Phil Delgyado in Архитектура ИТ-решений
О, доклада не слышал. Видео уже есть?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
В том и фишка. Не получается один к одному. Поэтому название паттерна не корректное.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Но главное, выравнивание с бизнесом происходит через стейкхолдеров от бизнеса
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Там две фигни: 1. не получатеся сделать самостоятельные команды в сложном окружении. Нужно много экспертизы извне.
2. Владение кодом делает команду узким местом для проекта.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Gennadiy Kruglov
Но главное, выравнивание с бизнесом происходит через стейкхолдеров от бизнеса
А тут не понял, как это связано.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Мне нужно подумать как хорошо объяснить
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Gennadiy Kruglov
Крис Ричардсон сегодня написал
выглядит как возврат в монолиты, ведь монолит это и есть service per team)
У нас есть свои особенности:
1) команда обычно владеет больше чем одним сервисом
2) набор команд меняется, сервисы и бизнес-процессы передаются во владение другим командам

и все-таки я хотел сказать что границы сервисов определяются по прикладным доменам (задачам), а также и команды формируются по прикладным доменам, так, чтобы сложность структурировалась по продуктам/доменам, команды формировались по продуктам/доменам, одним сервисом владела одна команда
источник

Kайржан Турмагамбетов in Архитектура ИТ-решений
Roman Tsirulnikov
выглядит как возврат в монолиты, ведь монолит это и есть service per team)
У нас есть свои особенности:
1) команда обычно владеет больше чем одним сервисом
2) набор команд меняется, сервисы и бизнес-процессы передаются во владение другим командам

и все-таки я хотел сказать что границы сервисов определяются по прикладным доменам (задачам), а также и команды формируются по прикладным доменам, так, чтобы сложность структурировалась по продуктам/доменам, команды формировались по продуктам/доменам, одним сервисом владела одна команда
А можно поподробнее 2 пункт. Начинают одни, завершают вторые?
источник