프로젝트 돌아보기(22.09.02TIL)

기다리던 6주차를 맞이할 수 있게 되었다. 하지만 합격된 기쁨과 동시에 도메인 모델에 미흡한 부분들을 피드백받았다. 이월 당하고도 도메인모델을 완벽히 이해하지 못한게 조금 아쉽다. 그래서 오늘 피드백 받은 부분을 바탕으로 내 마카오톡을 수정한다면 어떻게 해야할 지 돌아보았다.

 

🤸‍♂️

문제점

1. 도메인 하나가 다른 주요 도메인을 리스트형태로 감싸서 관리한다. 하나의 도메인이 모든 내용을 다 처리하다보니 객체끼리의 상호작용은 커녕, 책임이 한곳에 몰려 200줄짜리 도메인 객체가 탄생하게 되었다. (책임이 증가하니 당연히 테스트코드도 비대해져 버렸다.)

 

2. 관계라는 도메인을 설정함에 있어서 불필요한 분리가 발생했다. 결국 관계라는 도메인은 두 객체의 아이디를 하나의 아이디에 저장하는 구조인데, 굳이 유저 - 유저, 유저 - 채팅방, 채팅방 - 메시지로 분리를 해서 부자연스러운 도메인이 탄생했다.

이전엔 어떻게 했었지?

나의 부족한 지식으로는 정확한 해결책을 찾을 수 없어서, 아샬님이 작성하신 4주차 마카오뱅크, 노아님이 피드백 해주신 딜리버리 타이쿤을 떠올려 보았다. 생각해보면 어떤 과제에서도 다른 도메인 전체를 감싸는 거대한 도메인은 없었다. 마카오뱅크에서는 TransactionResult가 Transaction을 들고있었지만, 누가봐도 자연스러운 의존 구조였고 딜리버리타이쿤에서도 Delivery Game이 배달게임을 준비하는데 필요한 Order과 Food만을 참조하고 있었다. 언제나 말이 되는 구조인가를 고민해야 한다. 내 프로젝트에서 너무 많은 패널을 분리해서 전달해주기 어렵더라도 각각의 리스트를 따로 전달해서 필요한 객체의 상호작용을 만들어내자. (각각 도메인이 행동의 주체가 되어야 한다)

관계설정

id - id 쌍을 상태로 가지는 관계라는 도메인 하나로 모든 관계를 해결할 수 있다. 굳이 불필요한 새로운 도메인을 만들지 말자.

 

앞으로도 복잡한 객체지향 프로그램을 만들면서 어떤 구조가 좋은 구조인가에 대해 끊임없이 고민해야 하는데, 이번 프로젝트에서 시행착오를 겪고, 피드백을 통해 한단계 앞으로 나아갈 수 있어서 기쁘다. 위의 2가지 고민과 내 나름의 결론을 상기하면서 프로그램을 작성해야겠다!