💡 해당 포스팅의 내용은 정확하지 않습니다! 궁금한 점이나 의문점, 틀린점 등에 대한 댓글은 언제나 환영합니다.또한 내용이 상당히 어려우니, 멀티 모듈과 도메인 규칙에 대한 기본적인 이해 지식을 필요로 합니다.이전 내용을 다시 자세히 다루기엔 글이 너무 길어지고 번잡스러워지므로 양해 부탁드립니다. 🙇‍♂️(작성 순서대로 정렬)• 프로젝트 멀티 모듈화 고찰• 도메인 비즈니스 규칙과 멀티 모듈 아키텍처 설계• 다중 인프라스트럭처 도메인 모듈 분리를 위한 리팩토링📕 목차1. Introduction2. How to Structure Domain Services3. Implementing Domain Repositories: Query vs. Application Logic4. Designing Domain..

📕 목차1. Introduction2. Problems with the Existing Approach3. Direction for Architecture Improvement4. Refactoring Execution Strategy5. Real-World Application Case6. Advantages and Limitations of the Improved Architecture1. Introduction 📌 The Reason멀티 모듈을 구성하면서 잘 모르는 개념에 대해선 몸소 체험해보기로 결정했었다.점차 기존 설계의 결함이 보이기 시작했고, 이를 분석하여 정리해둔 적이 있었다. 하지만 도메인 모듈을 수정하면, 하위 모듈까지 영향이 전파될 것이 두려워 차마 손을 대지 못하고 있었다.그러다..

💡 예능적인 발상일 뿐, 실제로 시도하기엔 별로 좋은 방법이 아니라고 생각합니다. 아이디어만이라도 주워가실 분들은 읽어보세요!📕 목차1. Introduction2. Test Builder Pattern for Domain Rule3. Conclusion1. Introdution 📌 What's the problem?모든 코드는 깃헙에서 확인 가능합니다. 구현하고 있던 Usecase는 "채팅방에 메시지가 전송되었을 때, offline 혹은 백그라운드, 다른 뷰를 보고 있던 사용자에게 채팅 메시지를 푸시 알림으로 보여준다"였다.offline인 사용자의 경우 웹 소켓이 연결된 서버가 없기 때문에, 반드시 relay 서버에서 채팅 큐를 관찰해야만 하는 상황. 푸시 알림을 전송할 비즈니스 규칙은 본질적 복잡..

📕 목차1. Introcution2. How to Resolve?3. Lexicographical Sorting4. Consideration1. Introduction 📌 As-is빠른 저장 및 조회를 위해 Redis에 채팅 이력을 저장하여 관리하고 있는 상황.이 때, 채팅 아이디의 시간 기반 정렬(Time based sequence), 고유성(Unique)과 높은 동시성(High Concurrency)을 보장하기 위해 TSID를 사용하기로 결정했었다. 그리고 이 값들은 처음에 Hash로 바로바로 캐싱을 했었으나, 다음과 같은 문제로 Sorted Set을 사용하기로 결정했었다.채팅 조회의 경우 범위 탐색이 빈번하게 발생함.해시 자체는 고유성을 보장하지만, 저장 순서가 보장되지는 않음. (id가 뒤늦게..