WIL - 2주차 (Software Design)

회사에서 프로젝트나 일을 하면서, ERD 를 그려본 적은 있었지만 그 외의 다른 설계 문서를 작성해 본 적은 없다.

사내 임직원들을 위한 마음 건강 플랫폼 개발을 주도적으로 진행했었는데, 비개발자인 현업과 소통하기 위해 요구사항과 간단한 화면정의서만 작성한 후 바로 구현을 시작했었다.

비교적 단순한 도메인이었기에 큰 무리 없이 개발은 완료했지만 시퀀스 다이어그램, 클래스 다이어그램, ERD 등 설계 문서를 작성하는 과정을 거쳤다면 더 명확하게 요구사항을 정의하고, 구현 하는 데에 고민하는 시간을 줄일 수 있었겠다는 생각이 들었다. 

무엇보다, 협업 하는 데에 큰 도움이 되었을 것 같다.

 

이번 과제를 통해 아래의 문서들을 작성해보았다.

• 요구사항 정리 / 기능 명세
• 시퀀스 다이어그램
• 클래스 다이어그램
• ERD(Entity Relationship Diagram)

요구사항 정의는 두 가지로 나눌 수 있다.

기능적 요구사항(Functional Requirements) → 시스템이 "무엇을" 해야 하는지

비기능적 요구사항(Non-Functional Requirements) → 시스템이 "어떻게 해야 하는지"

 

처음엔 기능적 요구사항을 어떻게 작성해야 할지 막막했는데, 우선 제약 조건(Constraints)들을 먼저 나열하고

이것들을 Happy Path(정상 흐름) 와 Fail Cases(예외 흐름)로 각각 보내주다 보니 구조가 잡혔다.

 

시퀀스 다이어그램은 초기에 User → Controller → Service → Repository 등 구현 측면에서 모든 단계를 그리려다 보니

너무 복잡해졌고, 기획자, 디자이너 등 커뮤니케이션이 어려울 것 같다고 생각하여 몇가지 단계를 생략하였다.

근데 지금 생각해보았을 때 조금 더 추상화 하여 도메인 간의 흐름만 작성했어도 좋았을 것 같다고 생각한다.

 

클래스 다이어그램은 도메인 개념 간 책임과 관계를 시각화 한 것인데, 연관 관계의 방향을 결정하는 데에 어려움을 겪었다.

설계, 구현 관점에서 본다면 참조 방향을 기준으로 화살표 방향을 정해야 하고 도메인 개념 관점에서 본다면 개념적 포함관계를 기준으로 잡는 것이라고 이해했는데.. 아직도 헷갈린다!

예를 들어 Like와 Product의 관계에서, 구현상으로는 Like 클래스 안에 Product가 있으니 Like가 Product를 참조하지만, 도메인 개념상으로는 "상품은 여러개의 좋아요를 가진다"고 이해하여 Product → Like 방향으로 설정하였다. 리뷰 포인트에도 적었는데 조금 더 고민해봐야겠다.

 

ERD는 다른 것들에 비해 그나마 비교적 쉽게 작성할 수 있었는데,

- 외래키는 ref_user_id 형식으로 명시

- 모든 테이블에 created_at, updated_at, deleted_at 컬럼 포함

- 상태 전이를 표현할 수 있도록 status 컬럼 사용

등 몇몇 팁을 알게 되었다. 또한 ERD 상에서는 FK를 정의하더라도, 구현 단계에서는 약한 결합을 위해 실제 FK 제약 조건을 생략하기도 한다는 점도 알게 되었다.

 

문서를 작성하면서, 요구사항에 정의된 도메인 외에도 재고(stock), 카테고리(category)등 더 추가해야 하는 것들이 있을까 고민이 되었는데, 이렇게 하다보면 끝이 없을 것 같아서 핵심 도메인부터 시작해 실제 구현을 진행하면서 점진적으로 확장해 나가야 겠다고 생각했다.

 

2주차 끝!