Closed 05AM closed 2 months ago
hye-on
commented
2 months ago 이에 대해 이견이나 좋은 의견이 있으시다면 공유해주시면 감사하겠습니다!
타임존 알아보느라 고생하셨어요! 좋은 것 같습니다.
홈 컨트롤러의 API를 각각 도메인의 컨트롤러로 이전
개인적으로 home 컨트롤러를 유지하는 것이 좋다고 생각해요! (응집도를 위해) home은 각 도메인의 요구사항과 다른 시점에 다른 이유로 자주 변경이 일어날 수도 있을 것 같아요 (디자인, 기획) 그래서 지금 유스케이스를 잘 표현하고 있다고 생각합니다! 의견이 다르시다면 넘겨주셔도 됩니다!
05AM
commented
2 months ago home은 각 도메인의 요구사항과 다른 시점에 다른 이유로 자주 변경이 일어날 수도 있을 것 같아요 (디자인, 기획) 그래서 지금 유스케이스를 잘 표현하고 있다고 생각합니다! 의견이 다르시다면 넘겨주셔도 됩니다!
어떤 의미인지 공감이 되고 저도 비슷한 생각입니다. 그런데 우선 홈 컨트롤러에 모여있는 기능들이(타임라인 조회, 아바타 대사 조회 등) 같은 시점에 변경이 될 가능성은 낮을 것 같습니다.
또한 저희가 DDD 설계를 차용하여 도메인 별로 패키지를 구분하고 있는데 home은 도메인이라기에는 별다른 업무규칙이 없는 것 같아 도메인이라고 표현하기 애매해 보이기도 했습니다!
또한 서버의 구조가 외부 요소의(기획이나 디자인) 변경에 크게 좌지우지되지 않는 것이 더 바람직하다는 생각이 들어, 해당 api들이 홈 화면에서 사용되더라도 그게 서버의 구조에서 드러나지 않았으면 하는 바람이 있었습니다. 만약 별다른 정책 변경 없이 단지 홈에서 해당 api를 사용하지 않는다는 것이 변경의 이유가 될 수 없을 것 같다고 생각이 들어 위의 구조로의 개편을 결정하게 되었는데 혹시 위 의견에 대해서 어떻게 생각하시나요?
혜온님과 의견을 비슷하게 갖고 개발하고 싶어 코멘트를 남깁니다!
hye-on
commented
2 months ago 어떤 의미인지 공감이 되고 저도 비슷한 생각입니다. 그런데 우선 홈 컨트롤러에 모여있는 기능들이(타임라인 조회, 아바타 대사 조회 등) 같은 시점에 변경이 될 가능성은 낮을 것 같습니다.
컨트롤러에 있는 기능들이 아니라 각 도메인과 home에서 쓰는 도메인의 유즈케이스를 이야기한거였습니다!
또한 저희가 DDD 설계를 차용하여 도메인 별로 패키지를 구분하고 있는데 home은 도메인이라기에는 별다른 업무규칙이 없는 것 같아 도메인이라고 표현하기 애매해 보이기도 했습니다!
업뮤규칙은 저희가 스터디한 클린아키텍처에서 나오는 의미이겠죠?(사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차) 업무규칙이 없지만 auth같은 것은 역할이 명확하기 때문에 도메인이라고 표현은 안하지만 분리할 수 있었던 것 같습니다.
또한 서버의 구조가 외부 요소의(기획이나 디자인) 변경에 크게 좌지우지되지 않는 것이 더 바람직하다는 생각이 들어, 해당 api들이 홈 화면에서 사용되더라도 그게 서버의 구조에서 드러나지 않았으면 하는 바람이 있었습니다.
서비스처럼 코어한 부분이 외부 요소에 의해 바뀌면 안된다고 생각합니다. 그래서 표현영역에 위치하는 컨트롤러를 분리하는 것이 언급해주신 "소리치는 아키텍처"에서 의도하는 것이랑 더 잘 들어맞는다고 생각해요. 그리고 home, onboarding같은 경우는 컨트롤러를 따로 분리하는 경우를 많이 봤는데 이유를 찾고 싶어서 찾아봤는데 자료는 못찾았습니다. (나중에 주변 개발자들에게 여쭈어봐야겠어요)
그나마 관련된 질문을 인프런에서 찾았습니다.
정답이 있는 문제는 아닌 것 같아요. 저라면 "도메인적인 의미"(라고 표현해야될까요)와 응집도, 결합도, 유즈케이스 명확성 사이에서 후자를 선택할 것 같습니다!
의견을 나누어서 재밌었습니다. (스터디 연장전 같기도 하고. 같은 프로젝트를 하면서 같이 책을 읽었을 때 얻을 수 있는 장점인 것 같네요 ㅎㅎ)
앞에서 언급한 것처럼 제 의견이 정답이라고 생각하는것은 아니여서 원래 찬미님 의견대로 진행해주셔도 좋습니다 👍
☀️설명
현재는 한국에서만 서비스하지만, 운영 중 서버에서 보내주는 시간과 실제 시간이 일치하지 않는 이슈가 있었습니다. 타임존을 정해주지 않고 LocalDateTime을 사용하는 현재의 상황에서는 다음과 같은 두 가지의 문제점을 발생할 수 있는데요,
서버를 마이그레이션/증설 할때마다 timezone 설정을 해주어야 한다.
sudo timedatectl set-timezone Asia/Seoul명령어로 수정해보았는데, java의 localdatetime에서 시간 값이 utc 시간대로 반환되었습니다.서버 인스턴스를 모든 리전마다 둘 수 없기 때문에 단일 타임존으로 실행하는 것은 실용성이 없다.
따라서 클라이언트에서 기기의 타임존을 받아 해당 정보를 바탕으로 시간을 반환하기로 결정했습니다. 이에 대해 이견이나 좋은 의견이 있으시다면 공유해주시면 감사하겠습니다!
☀️작업 상세
☀️참고 사항
https://developer.apple.com/documentation/foundation/timezone https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/ZoneId.html
일치하지 않은 문자열 값에 대해서는 예외처리를 실행할 예정입니다.