chap00의 단순함은 장점이자 기준점이었다

chap00에서는 회원, 상품, 주문, 배송이 하나의 애플리케이션 안에서 끝났다.

처음 학습 단계에서는 이 구조가 매우 강력했다.

전체 흐름이 한 눈에 들어오고, 실행과 테스트 시작도 쉬웠기 때문이다.

하지만 그 단순함은 어디까지나 “지금 단계에서는 충분했다”는 뜻이지, 언제까지나 같은 구조로 가도 된다는 뜻은 아니다.

역할이 커지면 하나의 애플리케이션이 답답해지기 시작한다

주문 시스템 안에는 서로 다른 성격의 책임이 섞여 있다.

• 회원 인증과 사용자 정보
• 상품 조회와 재고 관리
• 주문 생성과 취소
• 배송 생성과 취소

처음에는 이 책임들이 함께 있어도 괜찮다.

하지만 구조를 조금만 더 현실적으로 보기 시작하면 질문이 생긴다.

• 상품과 주문은 같은 변경 단위여야 할까
• 배송 기능을 따로 다루고 싶다면 어떻게 해야 할까
• 일부 기능만 수정해도 전체 애플리케이션을 다시 띄워야 하는 구조가 계속 괜찮을까

이 질문들이 쌓이기 시작하면, 하나의 애플리케이션으로 모든 책임을 묶어 두는 방식이 점점 답답하게 느껴진다.

분리는 기능을 쪼개는 일이 아니라 책임을 나누는 일이다

chap01에서 일어나는 변화의 핵심은 “프로젝트를 여러 개로 늘렸다”가 아니다.