Size: a a a

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

2019 December 27

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Phil Delgyado
Можно попробовать оценивать не сам сервис, а дизайн ревью на его изменения. Насколько они сложные
Это кстати отличная мысль.
Может быть ревьюер и сторонний бизнес-домен не понимает (не сможет осознать правильность устройства сервиса),
но точно увидит странные, костыльные, нелинейные изменения в реализации типовой задачи. А это и будет сигналом к ревью архитектуры.
источник

K

Kostya in Архитектура ИТ-решений
Ну это в общих чертах
источник

RT

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

PD

Phil Delgyado in Архитектура ИТ-решений
Ну и процесс переноса сервисов в 'публичный домен', если очередь на них выросла.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Что такое публичный домен?
Очереди быть вообще не должно: команда делает проект и самостоятельно дорабатывает все сервисы, в которые нужно внести изменения.
Синхронизация работы команд с ожиданиями работ это тот самый ватерфолл.
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Roman Tsirulnikov
Что такое публичный домен?
Очереди быть вообще не должно: команда делает проект и самостоятельно дорабатывает все сервисы, в которые нужно внести изменения.
Синхронизация работы команд с ожиданиями работ это тот самый ватерфолл.
MQ
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Кролик
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Кролик это технический инструмент интеграции, причем тут домен?)
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
У тебя должен быть legacy-чувак
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Который делал всё по 'уму', а получил big ball of mud
источник

A

Alexey in Архитектура ИТ-решений
Kostya
Кто больше в бизнес процессах погружен ит.д., кто меньше деталям уделяет внимание
"Кто правильнее" и "кто больше" - ИМХО не очень критерий, т.к. (1) компаративен, т.е. работает, когда надо сравнивать N претендентов друг с другом, и (2) опять-таки субъективен (если, конечно, у вас нет источника объективной истины). И мы возвращаемся на исходную: это очень субъективно.
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
источник

K

Kostya in Архитектура ИТ-решений
Alexey
"Кто правильнее" и "кто больше" - ИМХО не очень критерий, т.к. (1) компаративен, т.е. работает, когда надо сравнивать N претендентов друг с другом, и (2) опять-таки субъективен (если, конечно, у вас нет источника объективной истины). И мы возвращаемся на исходную: это очень субъективно.
Реляционно
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Kostya
Реляционно
Нет
источник

K

Kostya in Архитектура ИТ-решений
Абсолютно
Зависит от цели найма
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
С пляжа relation & comrads
источник

K

Kostya in Архитектура ИТ-решений
Дайте тесты, будет объективно
источник

K

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

K

Kostya in Архитектура ИТ-решений
В цифрах нах
источник

K

Kostya in Архитектура ИТ-решений
О чем речь, камрады ?
источник