design_pattern_msg_v1
발단
내가 생각을 해봤는데...
디자인 패턴을 적용해보고 싶은데 단순히 책만 보고 예제를 따라하면 그 순간에는 잘 아는 것 처럼 생각이 들수 있어도
막상 해보려면 글쎄... 적용을 못할 것 같다는 생각이 들었다.
실제로 회사 프로젝트에서 프리똥쟁이들이 만든건지 싸지르고(?) 간건지 모른 코드를 정리하다보니
좀있으면 롤아웃인 상황에서 이걸 할 수 는 없을 것 같고... 그렇다고 무슨 방법이 있을지 당장 떠오르지가 않았다.
프로젝트를 더 하면 할수록 시작부터 크게 볼 수 있는 시각을 가져야 하는데
이 똥쟁이(?)들이 생각없이 지른 코드들을 보면 정말 아찔했다. 고로, 나는 그렇게 되기 싫다는 생각에 다시 공부하려고 한다.
(이노무 프리x끼들아... 내 분노가 느껴지지 않니...? 니들이 사람이야? 빼액!)
예상 전개
그래서 기본은 객체지향을 중심으로 기본적인 DDD 부분을 JPA를 활용해서 적용해서 여러 패턴들을 공부해 나갈 생각이다.
DDD에서 출연한 기본적인 용어들과 개념들을 통해 같이 혼합해가며 작성하는 것이다.
내가 참고할 책은 크리스 에반스가 아닌... 에릭 에반스의 도메인 주도 설계, 오브젝트(Object) 그리고 DDD 주도 개발 마지막으로는 헤드퍼스트 디자인 패턴(head first design pattern)이다.
방향성
주로 하나의 도메인 정보로 모든 패턴을 덕지덕지 붙여볼 것이다.
특성 상황에서 패턴을 딸랑 하나만 쓰는 경우는 없으니 말이다.
그러기 위해서는 내가 다시 책을 다 꺼내서 다시 읽어봐야 할 것이다. (사실 이것도 엄청 고생이긴 했다.)
핵심 도메인
내가 핵심적으로 사용할 도메인은 객실 예약 시스템이다.
즉, 객실 예약 시스템이 소프트웨어로 내가 해결하고자 하는 도메인에 해당한다.
이를 구현하기 위해서는 요구사항을 정확하게 이해하는 것이 필요하다. 고로, 이에 대한 요구사항도 상세히 정리할 예정이다.
내용 적어보기
우리가 숙소를 예약한다고 해보자. 여기서는 객실이라고 하겠다. 객실을 예약한다고 생각해보자.
우선 우리가 사용할 객실을 본다. 배치된 객실을 본 후, 예약을 할 것이다.
예약을 하는 동안 예약 가능한 객실이 보일 것이다. 이미 누가 사용하는 경우, 이미 예약이 된 경우, 객실이 정비중인 경우 등 여러 경우가 있을 것이다.
그 사용 가능한 객실 중 에서 우리는 선택을 해서 예약을 할 것이다. 예약을 하면서 결제를 할 수도 있고, 직접 와서 결제를 할 수도 있다.
피치 못할 사정으로 사용자가 오지 못해서 환불을 요청하는 경우가 있을 수 있다. 그러한 경우 하루 전 예약 취소시, 12시간 전 취소시, 6시간 전 취소시 불이익이 있을 수 있다. 즉, 시간에 따라 차등적으로 환불 금액을 추가할 수 있다.
또한 객실 이용에서 고객에 한해서만, 아니면 특별 이벤트를 통해서 할인을 받아서 사용할 수도 있을 것이다. 필자는 다양한 객실 할인에 대해 적용할 예정이다.
요금은 또한 성수기, 비성수기 지정 기간에 따라서 변할 수 있다. 보통 금요일, 토요일은 성수기이며 여름 휴가철, 겨울 휴가철에도 성수기가 될 수 있다. 또한, 공휴일이 긴 경우 성수기로 볼 수도 있다.
자, 이러한 정보를 토대로 사용자가 예약을 하고 알림이 고객에게 간다. 그리고 잘 사용한다.
그러면 이러한 예약내역도 추후에 관리할 수 있고 어느 방이 잘 나가는지도 확인할 수 있을 것이다. 고객 혹은 비회원도 스스로 얼마나 객실 예약을 했는지 알 수 있다.
그리고 후기를 남겨줄 것이다.
그림 그리기
다이어그램? 이라고해야하나? 한 번 관계도를 그려보긴 했는데 이게... 괜찮은거 같기도 하고...? ㅎ... 해당 정보는 Issue에 애그리거트 및 다이어그램 에 올려놓앗다.
다른 애그리거트간에 연결은 루트 애그리거트를 통해서 보통 통신을 한다고 하는데,
다른 방법을 고려할 수 있다고 한다.
-
도메인 이벤트: 한 애그리거트에서 중요한 상태 변화가 발생했을 때 도메인 이벤트를 발행하고, 다른 애그리거트가 이 이벤트를 구독하여 필요한 동작을 수행할 수 있습니다. 이 방식은 애그리거트 간의 결합도를 낮추면서도 유기적인 통신을 가능하게 합니다.
-
서비스 레이어: 애플리케이션 서비스 레이어나 도메인 서비스를 사용하여 여러 애그리거트 간의 통신을 조정할 수 있습니다. 이러한 서비스는 다른 애그리거트의 API를 호출하거나, 필요한 도메인 로직을 수행하여 애그리거트 간의 상호 작용을 관리합니다.
-
명령과 쿼리의 분리 (CQRS): 명령(상태를 변경하는 작업)과 쿼리(정보를 조회하는 작업)를 분리하여 애그리거트 간의 상호 작용을 관리할 수 있습니다. 이 방법은 복잡한 도메인에서 읽기와 쓰기 작업의 모델을 분리하여 성능과 유지보수성을 향상시킬 수 있습니다.
머... 틀리면 고치면 되지
다만 이제부터는 해당 내용은 issue에서 따로 관리하려고 한다.
처음이다보니 부자연스럽고 이상한 부분이 너무 많아서 그렇다.