이번 포스팅은 올려 올려 라디오 프로젝트의 도메인 모델 개선에 대해 다룹니다.현재 도메인 모델의 문제점을 짚어보고, 더 나은 도메인 모델을 제시하면서 그 근거를 정리하겠습니다. 시작하기 앞서, 프로젝트 리팩토링 과정을 잘 이해하기 위해 우리 프로젝트가 어떻게 동작하는지 간단하게 짚고 넘어가겠습니다.프로젝트 동작 구조답장 서비스 동작 구조위 그림은 우리 프로젝트의 첫 번째 MVP인 `답장 서비스`가 동작하는 구조입니다.유저가 `편지`를 써서 전달하면 생성형 AI가 `답장`을 생성해 응답합니다.우리 프로젝트는 유저가 작성한 `편지`와 `답장`을 각각 별개의 엔티티로 관리합니다.두 엔티티 간 관계는 1:1 관계를 갖고 있습니다. 데일리 리포트 서비스 동작 구조우리 프로젝트의 두 번째 MVP인 `데일리 리포트..

데이터 주도 설계에서 책임 주도 설계로프로젝트를 유지보수하고 새로운 기능을 개발할 때마다 `데이터 주도 설계`를 해오고 있다는 느낌을 지울 수 없었습니다.해커톤 기간은 10일만 주어졌고, 이 기간 동안 개발하던 프로젝트가 한 번 엎어져 남은 기간이 6일밖에 안 됐던지라 객체 지향적인 협력 관계를 고려하지 못한 채 개발을 이어나갔습니다. 해커톤 종료 후 고도화 기간 동안 설계를 재점검하지 않고 유지보수와 새 기능들을 개발했는데, 코드를 읽을 때마다 여기저기 중복된 코드와 제각기 다른 구현 방식 때문에 코드 읽기가 힘들었습니다.원인은 객체의 행동이 아닌 상태에 초점을 둔 데이터 주도 설계 때문이라고 생각되어 문제 해결을 위해 조영호 님의 오브젝트를 다시 읽었습니다. 이번 포스팅을 시작으로 `책임 주도 설계`..