7장의 서비스 분해인/통합인에서 이 부분에 대해 설명을 아주 잘 해주긴 하더라고요.
제가 생각한 단점도 비슷합니다.
분해한 서비스들 끼리의 호출 횟수, 응답 속도, 그렇게 함으로서 워크 플로의 오케스트레이션의 복잡도 증가 등을 고려해야 하는데, 그런 것들의 객관적 수치로 제시되고 분리가 되었는지에 대해 면밀한 분석이 필요하다고 봅니다.

그리고 이 책이 계속 얘기해주는 건 객관적인 데이터 증거를 통한 아키텍처 결정을 의미있게 해보자인 거 같고
특히 한빛가이버 사가의 대화들과 마지막 ADR 기록이 그 부분을 잘 보여주고 있어서 더 이해가 잘 되는 것 같습니다.

서비스를 이상적으로 정말 적절하게 나누고 그것이 제품 판매 종료 전까지 잘 유지된다는 가정하에는 단점이 거의 없을 것 같긴 하네요

지금 생각나는 건 독립된 서비스간 아무래도 코드를 공유하지 않다 보니 중복된 코드 (특히 유틸리티 함수 등) 가 많아지는 정도의 딘점이 생각나는데 이것도 사실 서비스 통합인 중의 하나로 언급되고 있어서 궁극적으로 책이 말하는 단점은 아닐것 같습니다

이 책의 저자가 생각하는 이키텍처 결정의 기준이 객관적 데이터가 문장 수나 인터페이스 개수로 측정하는 걸 얘기하는 거라고 생각합니다. 다른 책에서도 데이터의 입력 출력 갯수로 작업의 단위를 계산하고 분석 단위로 하는 것도 있었으니까요.
만약 얘기하신대로 장애 상황이 빈번하면 그것도 세분도의 객관적 데이터로 볼 수 있을 것 같습니다. 사후 세분도 측정 데이터인 셈이겠죠.
제 예상에는 아마 이 책의 후반부에 그런 설명을 하지 않을까 싶네요.

다른 저자분이 쓴 아키텍처 책을 보고 다른 관점에 대해 이해하면 좋지 않을까 싶습니다.
저도 어려울 수도 있는 부분을 참 쉽게 설명을 잘 해주는 구나 라는 느낌을 많이 받고 있습니다.