도메인 설계(22.12.03TIL)

전체 기능 중 핵심 기능으로 추려놓은 강의 시청, 채팅방, 쓰레드, 타임라인기능을 인수테스트 문서작업을 마무리 하고 도메인에 대한 고민을 해보았다. 형과 대화하다보니 형은 도메인 설계에 대한 밑그림을 거의 대부분 구상해놓은게 느껴졌는데, 나는 도메인에 대해 막연하게 생각하고 있는게 느껴져서 고민해보게 되었다.

저번 레벨테스트에서의 문제점

5주차 레벨테스트에서 만든 어플리케이션은 전혀 객체지향적이지 않았다. 메인 클래스가 모든 기능을 전부 들고 있어서 혼자 모든걸 다해내는 구조였기 때문이다. 스프링의 도움과 명확하게 가이드된 과제 덕분에 아직까지는 문제를 일으키지 않았지만, 다시 나 스스로 도메인 설계를 해내야 되는 포트폴리오 주간을 잘 해낼 수 있을까 걱정이 되었다. 도메인에 대한 지식을 정리하기 위해 저번에 홀맨님이 올려주신 조영호님의 우아한 객체지향 유튜브를 보고 다시 정리해보기로 했다.

우아한 객체지향

의존성 관점으로 리팩토링하기

백엔드에서도 마찬가지로 코드를 빠르게 짜고 리팩토링을 거쳐 좋은 코드로 탈바꿈하게 된다. 하지만 어떤 것을 기준으로 리팩토링해야할 지 감이 오지 않았는데 이 강의에서 힌트를 얻을 수 있었다. 의존성 관점에서 설계를 검토하면서 리팩토링을 진행한 것이다. 이러한 접근법이 매우 신선하게 느껴졌다.

의존성 설계시 주의할 점

코드를 짜고 의존성 관점에서 설계를 검토하다 보면 두가지 문제가 발생하는데 보통 다음 문제가 생긴다.

객체 참조로 인한 결합도 상승

같은 트랜잭션안에 묶인 객체들은 같은 생명주기를 가져야 한다. 만약 변경의 빈도가 다른 객체끼리 묶여있다면 트랜잭션 경합으로 데이터베이스에 락이 걸릴 수 있다. 객체를 직접 참조를 아무때나 써도 되는게 아니라 정말 필요한 곳에서만 해야 실제 서비스에서 문제 없이 서비스를 사용할 수 있다는 점을 알게되었다.

패키지 의존성 사이클 발생

도메인 설계를 하다보면 패키지 단위의 양방향 의존성이 발생할 때가 있다. 이 경우에도 도메인간의 양방향 의존성과 마찬가지로 잘못되었다는 신호이다. 이럴 경우에는 중간 객체를 생성하거나 인터페이스를 만들거나 패키지를 분리해서 의존성을 단방향으로 옮겨줄 수 있다.

 

월요일부터는 스프린트 시작을 하게되는데, 실제 코드를 짜기 전에 당장 필요한 핵심기능들은 클래스 다이어그램으로 어느정도 방향성을 잡고 도메인 설계를 진행해야 할 것 같다. 내일은 먼저 클래스 다이어그램을 빠르게 짜보고 우아한 객체지향 강의에서 나왔던 의존성 설계 주의점에 부합하는지 검토하는 시간을 가져보자.