[refactor]도메인 모델 확립에 대한 회의 (진행 예정)

[2chang5]

주제 설명

Pre

의도

• 서버에 보낼 때 id가 아직 없는 상태이다. 때문에 id가 없는 객체가 필요하다. (인자를 객체로 묶기 위함)

  ⇒ 현재, id 값이 서버 의존적

• id가 null인 것은 추가적인 로직이 많아진다.(공수가 많이 듦)

• 따라서 create의 용도로 id를 제외한 모델을 사용했다.

문제점

• 도메인(기획)보다는 DTO 처럼 외부 요인의 영향을 많이 받는다
• 기준이 모호하다.(create 뿐만 아니라 update에서도 필요하다.→ 외부의 영향을 계속해서 받게된다.)

방안

1. 외부 통신과 내부 기능 다 하나로 몰아 불필요한 것은 nullable로 한다

외부 서버 통신 DTO가 각각 달라도 그 모든 값을 포용 = 모든 값 다 갖고 있음

장점 : 현재보다 도메인 변화 줄어듦

단점 : 도메인 모델 거대화될 수 있음

2. 내부 회의를 통해 적절한 기준에 따라 도메인 모델 생성

장점 : 도메인 모델 거대화 방지

단점 : DTO에 휘둘릴 가능성 있음. 현재 방식(기준이 정확해야 함)

각자 의견

멧돼지

1번 : 어짜피 외부 api 를 사용하려면 안정성을 위해 nullable로 뚫어주어야한다. 관련 null 처리 로직을 강화하는 것이 맞다고 생각한다. github api 등 타 api를 보면 어쩔 수 없이 model이 거대화된다. 거대화된다면 그 때 가서 2번에 따라 기준을 나누는 것이 낫다고 생각한다.

SRP와 ISP 원칙에 어긋난다고 생각한다.

수달

1번을 택하되, 그 안에서 관련 모델들을 묶자

→ 멧돼지 : 1번을 따랐을 때, 모델이 거대화되다보면 nullable인 것들을 동반해서 사용할 수 밖에 없다. 이때 통합적으로 같은 도메인 모델을 사용할텐데 depth가 깊어진다면 파악하기가 어려워진다.

핑구

2번 : 다같이 회의를 통해 서버를 고려하지 않은 우리가 생각하는 Trip과 Post가 무엇인지 정의를 해놓는다면 그에 맞는 도메인을 만들 수 있을거라 생각한다.

필요 태스크

• 추가 회의
• 도메인 적립