Size: a a a

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

2019 November 19

GK

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

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

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Команда - это обработчик требований одного или нескольких бизнес стейкхолдеров (бизнес юнитов)
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Kайржан Турмагамбетов
А можно поподробнее 2 пункт. Начинают одни, завершают вторые?
скорее делают одни, а потом, через год, сопровождать и наращивать функциональность могут уже другие. а могут и те же, it depends от планов бизнеса
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
у нас нет ситуаций “доделывают другие”, команда не расформировывается до завершения проекта
источник

GK

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

RT

Roman Tsirulnikov in Архитектура ИТ-решений
У нас главный вызов это сопровождение и доработка огромного количества старого кода, большого количества работающих бизнес-процессов.
источник

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Вот эти модули, на самом деле очень похожи на приложения. Ричардсон говорит об App per team
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Как-то так, сыровато пока
источник

Kайржан Турмагамбетов in Архитектура ИТ-решений
App может быть монолит и из микросервисов. Все ещё не понятно)
источник

GK

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Kайржан Турмагамбетов
App может быть монолит и из микросервисов. Все ещё не понятно)
Да, конечно
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Монолит - это то, что развёртывается как единое целое
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
При этом он может быть распределённым
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Подсмотрел по вышеприведенной ссылке новый термин, буду пользоваться:


The size and complexity of the team’s code base must not exceed the team’s cognitive capacity.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
team cognitive capacity,
осталось подобрать метрику
источник

Kайржан Турмагамбетов in Архитектура ИТ-решений
Team тут чисто дев? Или аналитики тоже?
Можно ли взять процент ошибок как метрику? Или скорость разработки в чел/часах на 1 бизнес требование
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
я думаю это неважно, просто Ричардсон разработчик, поэтому говорит про код.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
По-разному. Это могут быть команды Бека и Фронта, например. Или две команды Бэка и одна Фронта. Важно что у них общий бэклог и они выкатываются вместе.
источник