👨‍👩‍👧‍👦 Project/📩 DevTalk

1. 문제상황 Repository단에서 Command와 Query를 분리하여 책임을 분리함으로써 코드 응집도와 유지보수성을 높이고자 하였다. 이에 처음 시도했던 방법은 아래와 같다. Create, Update, Delete를 담당할 CommandableRepo Interface와 Read를 담당할 QueryableRepo Interface로 나누었다. 구현체는 CommandRepo, QueryRepo로 구현한다. 하지만, 문제가 생겼다. 어떠한 엔티티를 save해야 하는 상황을 가정할 때, 중복조회나 다른 조회 메서드를 이용해야 하는 상황이 주로 발생했다. 이럴때, Repository를 사용해야 하는 Service 계층에서 의존성이 너무나 많아지는 문제가 발생했다. 2. 문제해결 과정 1 - interf..

✢ 프로젝트에서 헥사고날 아키텍처를 적용하기로 했고, MSA 방식으로 각자 분리된 담당 서비스를 개발한다. 아무리 분리된 서비스라고 해도 처음에는 패키지 구조나 네이밍 컨벤션을 정해놓는 게 추후에 서로 코드리뷰할 때 편하고 여러 장점이 있는 것 같아서 미리 설계하였다. 1. 헥사고날 아키텍처 구조 에 대한 것은 이전 포스팅을 확인해주세요. 2023.07.06 - [👨‍👩‍👧‍👦 Project/📩 DevTalk] - 헥사고날(Hexagonal) 아키텍처를 공부해 보자 (with Layered, Clean Architecture) 2. 내가 생각한 패키지 구조 src.groupname ㄴ global ㄴ config ㄴ util ㄴ error ㄴ exception ㄴ handler ㄴ {애그리거트 이름} ㄴ..

✢ 데브톡 프로젝트에서 헥사고날 아키텍처를 적용해 보자고 제안해 보기 위해 공부하였고 내용을 정리하였다. 적용해보고자 하는 이유는 데브톡은 MSA로써 Port&Adapter 아키텍처인 헥사고날 아키텍처를 사용하는 게 의존성을 관리하기 좋을 것 같았기 때문이다. (1) 전통적인 레이어드 아키텍처의 문제 1. 데이터베이스 주도 설계를 유도한다. 전통적인 계층형 아키텍처의 토대는 데이터베이스이다. 웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스럽게 DB에 의존하게 된다. 우리가 보통 개발하는 애플리케이션의 목적은 비지니스를 관장하는 규칙이나 정책을 반영한 모델을 만들어서 사용자가 편리하게 사용할 수 있게 하는 것이다. 이때 우리는 State가 아니라 Behavior를 중..