Крутой доклад!
А кто-нибудь привнесенные баги трекает(измеряет)? Если да, расскажите как.

хорошая метрика это Deffect Removal Efficiency - соотношение багов которые нашли внутри и снаружи. Условно если вы нашли и пофиксили баг и его не нашли клиенты - молодцы. И не важно сколько было багов. Важно что бы они до пользователей не добирались

количество багов будет на другие метрики влиять (вроде cycle time/lead time/etc) как отвлекающие факторы, на качество влияют только выбравшиеся баги

Ага, ну такая сдерживающая получается, как error budget

тип того

В целом в небольших масштабах (команда) не думаю что польза будет т.к. все же баги не часто и достоверной статистики не наберёшь, лучше просто лучше обращать внимание что к такому багу привело (ретроспектива)
Просто если учёт багов вести, нужно же атрибутировать его к моменту внесения, так?. А то будем мерить скорость их поиска в ином случае

да, это больше на уровне организации или подразделения/продукта полезно, как сигнал что "шот у вас не так идет". В целом так же как и всякие mean time to recovery и т.д.

Всем привет! У меня вопрос по application слою, а точнее к чему он принадлежит.

Вернон предлагает два подхода: на каждый контекст делать свои application сервисы или сделать один общий application слой для всего приложения.

Мне кажется, что первый подход удобен для микросервисов, даже если начинать с монолита. В случае выделения какого-то контекста в отдельный микросервис скорее всего будет достаточно только создать ui слой. Но в случае с монолитом придется в контролеерах оркестровать юзкейсам, что создаёт небольшие неудобства.

Второй подход хорошо применять для монолитных приложений. Тогда application слой станет api всего приложения на который можно натянуть ui слой без доп оркестровки. Но в случае выделения отдельного контекста в микросервис, скорее всего под него придется писать еще свой application слой и сверху ui.

Правильно ли я понимаю плюсы и минусы каждого подхода? И есть ли бэстпрактис на этот счет?

почему ты думаешь что для микросервисов и монолитов с точки зрения декомпозиции кода что-то отличается?

Ну я же написал, что если у меня свой application слой у каждого контекста, то этот слой уже будет выступать как api микросервиса.

И мне кажется в таком случае придется писать меньше кода. По сути api готов

надо бы вернона перечитать побыстрому... не помню уже че за чушь он там предлагал

Почему чушь и как еще можно это сделать?

Понятно, что контексты могут общаться эвентами, но это не для всего подходит как мне кажется

Я так понимаю это достигается за счёт одной очереди и одного консюмера?

Просто если несколько обработчиков, что помешает сделать несколько обращений к одному агрегату в фоне, подобно http?

есть разные стратегии. можно партицировать очереди и обработчики у тебя будут со своими партициями работать, тогда никаких конфликтов. Можно делать оптимистичные локи и ретраи которые пофиксят out of order выполнения всякие и прочие конкаренси (как nservicebus делает)

Спасибо :)

Я тут скрины книги вернона сделал, где он говорит про application слой общий и раздельный

Подскажите где можно детальнее прочитать про eventual consistency, а то в каждой второй статье термин фигурирует, а до конца понимания нет. Спасибо