화면설계와 DB설계만?

우리가 개발하는 Application(System)은 크게 3개 Tier로 나뉜다.
(참고 - Layer : 논리적인 계층, Tier : 물리적인 계층)

(1)화면(UI, Presentation)  --->  (2)Application Server(Backend)  ---> (3)DB Server

3번의 데이터 영역은 분석단계 데이터 모델링부터 ERD를 그려 정의하고, 설계단계 DB설계 및 데이터 전환까지 잘 설계/구축한다. 그리고 1번 화면도 분석단계 화면 스케치(정의)부터 고객 Confirm하고 화면설계까지 PPT로 그림까지 그려가면서 잘 설계/구축한다.

1번 화면 및 3번 데이터 영역은 누가 시키지 않아도 누락없이 적절한 도구를 가지고 어떻게든 설계하려고 애쓴다. 

그럼 2번 Backend 영역은 어떤가?

규모가 작은면 작을수록 잘 설계하려 하지 않는다. 규모가 커서 감리나 품질의 견제에 못이겨 설계하긴 하지만 칸만 대충채우려는 경향이 있다. 아예 설계하지 않는 경우도 많다. 화면과 DB설계만 하고 Backend는 적절히 복사/붙여넣기 하면서 바로 개발한다. 바로 코딩한다. 설계도 개발도 잘 하는 경우도 있지만 그렇지 않은 경우가 많기에 하는 말이다.

 

대부분 그렇지 않다는 것은 Backend 서비스는 설계없이 개발해도 문제 없기 때문에 그런것 아닌가? 라는 생각이 들 수 있다. Controller -> Service -> Data Access 개발 표준이 정해져 있고 대부분 Bypass만 하고 ERD보고 쿼리만 잘 작성하는 되는데 굳이 Class들, Method들 간의 설계를 해야하나? 라고 생각할 수 있다.
과연 그럴까?

• 화면에서 또는 또다른 Application에서 사용할 수많은 API들을 Backend에서 제공해야 하는데 내가 어떤 API를 만들어야 하고 또는 누가 내 API를 호출하는지 설계없이 바로 개발해도 문제가 없는가?
• UI, API 뿐 아니라 Service의 로직, Data Access의 쿼리 등 수많은 호출관계에서 누가 사용하는지(Consumer), 누가 제공하는지(Provider)를 어떻게 파악할 수 있는가? 미리 고민하지 않고 그냥 개발해도 괜찮은가?
• 내가 필요한 API가 어디에 있는지, 누가 제공하는지, 어떤 Input와 Output을 제공하는지, 해당 API가 개발되기전에는 알 수 없을까, 즉 API 관리, 검색을 미리 해 볼 수 없을까
• API에서 어떤 로직을 호출하는지
• Service에서 어떤 Data Access를 사용하는지
• 공통 Service로직은 누가 어디서 관리하는지
• 입력 DTO/VO, 출력 DTO/VO 또는 입출력에 관계없는 통합 DTO/VO, DTO <-> Entity 간 변환은 언제 어디서 누가 하는지
• API 외에도 내가 호출하거나 내가 제공해야할 대내외 Interface는
• Message Queue를 통해 Event를 주고 받아야 한다면 API 뿐 아니라 Publisher, Subscriber, 어떤 이벤트를 누가 어디에서 어떻게 발행하고 누가 구독하는지
• 내가 개발해야할 전체 프로그램 모수(UI, Report, API, Batch, Interface 등)를 개발전에 미리 파악할 수 없는지, 누구와 협업해야하는지, 누가 설계하고 개발하고 단위테스트하는지, 그 일정이 부족한지, 넉넉한지, 미리 알 수 없을까
• META 표준 단어 적용은 어떻게
• 이외에도 Backend 설계 관련 고민할 사항이 많을텐데, 이러한 것들이 UI와 DB만 설계해도 Backend 짐작이 가능한가
• 일단 코딩시작해 보면 안다?
• 개발하기 전에 Simulation해서 전체 개발 모수를 파악하고 재작업을 줄일 수 있는 방법이 무엇인지

스스로 물어야 한다.

Backend 설계를 하나요? 

한다면 어떻게 하고 있나요? 

어떤 도구를 이용해서 설계하나요? Office 문서? UML 도구? Office도 UML도구도 아니라면 어떤 도구?

관련해서 WBS에 어떤 Task가 있나요?