• 서비스 간 교류하는 방식에 중점을 둔다: 이것은 문제 도메인(영역)에 대한 큰 단위의 인터페이스를 만드는 데 도움이 된다. 큰 것을 작게 리팩터링하는 것이 더 쉽다.
• 문제 도메인에 이해가 깊어지면서 서비스 책임도 계속 변한다: 새로운 애플리케이션 기능이 요구될 때 대개 마이크로서비스가 그 책임을 맡는다. 마이크로서비스는 단일 서비스로 시작하여 여러 서비스로 분화되며 성장하는데, 원래 서비스는 새로운 서비스들을 오케스트레이션하고 애플리케이션의 다른 부분 기능을 캡슐화하는 역할을 한다.
나쁜 마이크로서비스의 징후는 어떤 것일까? 마이크로서비스가 적절한 크기인지 어떻게 알 수 있을까? 너무 큰 마이크로서비스는 다음 징후가 있다.
• 책임이 너무 많은 서비스: 해당 서비스에서 비즈니스 로직의 일반적 흐름이 복잡하고 지나치게 다양한 종류의 비즈니스 규칙을 시행하는 것처럼 보인다.
• 다수 테이블에 걸쳐 데이터를 관리하는 서비스: 마이크로서비스는 자기가 관리하는 데이터에 대한 기록이다. 여러 테이블에 데이터를 유지하거나 서비스의 데이터베이스 외부에 있는 테이블에 접근한다면 서비스가 너무 크다는 징조다. 필자는 마이크로서비스가 3~5개 이하의 테이블을 소유해야 한다는 지침을 사용하고 싶다. 이보다 더 많다면 서비스가 너무 많은 책임을 담당할 가능성이 높다.
• 테스트가 너무 많은 서비스: 서비스는 시간이 지남에 따라 규모와 책임이 커질 수 있다. 서비스가 적은 수의 테스트 케이스로 시작해서 수백 개의 유닛 테스트와 통합 테스트로 끝나는 서비스가 있다면 리팩터링이 필요할 수 있다.