분석 -> 설계 -> 개발 과 같은 Waterfall 방식의 설계단계를 기본설계와 상세설계로 나누는 이유는 뭔가?
- 상세설계 및 개발 단계를 반복(Iteration)적으로 계획/실행하면서 Waterfall의 단점을 보완할 수 있다.
- 상세설계 및 개발 계획, 즉, 누가, 언제, 어떤 프로그램을 설계/개발/테스트할 것인지 전체 목록을 정리하고 Iteration Planning하는 때가 기본설계이다.
- 기본설계 단계 말, 프로그램 목록 또는 Backlog가 정리되어 있어야 설계/개발해야할 전체 모수를 파악하고 계획, 예측할 수 있다.
- 이를 위해서는 특히나 MSA 프로젝트에서는 API First Design 이 우선되어야 한다.
- 기본설계, 즉 API First Design 이 제대로 이행되지 않거나 생략하는 경우 내가 무엇을 개발(Provider)하고 다른 파트/서비스의 무엇을 호출해야할지 (Consumer) 모른채 상세설계 및 개발로 진입, 이후 단계에 협의하고 개발하기에는 늦음, 혼란, 지연, 재작업
- 기본설계에서 뼈대를 잡고, 상세설계에서 살을 채운다고 생각
- 기본설계 API First Design을 통해 API, Publisher, Subscriber와 같은 프로그램을 협의, 정의, 계획해야 함
- 기본설계 예 : Microservice, BizPackage, Controller Class, API Method, Service Operation 정의
- 상세설계 예 : Service Operation 내 Biz Logic, 조건문/반복문, Exception, 분산 Transaction 등
기본설계와 상세설계 및 개발을 나누지 않고 한번의 설계 후 개발하는 경우?
- 전체 설계/개발해야할 분량, 모수를 파악하지 못하고 상세설계로 들어가야함
- 즉, 설계/개발에 대한 공수산정 어려움
- 전체 골격, 뼈대를 설계하지 않고 상황에 맞춰 어떤 것은 뼈대 설계, 어떤것은 상세설계
- 타 파트와 무엇을 어떻게 주고 받을지에 대한 약속, 선후관계, 일정 등을 가늠하기 어려움
- 예 : 상대 파트/서비스에서 API 제공할 것이라 예상하고 우리의 로직을 상세설계/개발하고 맞춰보려했는데
- 상대 쪽에서는 전혀 고려하지 않고 있어 재설계/재작업/지연 발생
- 한번의 설계를 단계에서 기본설계와 상세설계를 한꺼번에 하려면 너무 복잡
- 위의 기본설계/상세설계의 고려사항을 한꺼번에 고민해야함, 혼란
