안녕하세요. 이벤트에 빠진 개발자 stark입니다!최근 저는 DDD에 푹 빠지게 되었습니다. 그래서 회사 선배님께 책을 빌려서 읽기도 하고 세미나도 보면서 정말 많은 공부를 하고 있습니다. DDD관련 책을 읽던 도중 '이벤트 소싱'이라는 목차가 등장했고 읽다 보니 엄청난 호기심이 생겼습니다. 왜냐하면 저는 주로 헥사고날 아키텍처와 EDA를 사용하여 개발을 해왔지만 제가 이벤트를 사용하게 되는 상황은 단순히 비관심사를 분리하는 상황뿐이었습니다. 특히 이벤트와 DDD와 조금만 검색해 봐도 Command와 Query를 분리하는 CQRS가 나옵니다. 그러다 보니 어느 순간부터 저도 코드에 "적용해 볼까?"라는 생각이 들면서 계속해서 고민하게 되었습니다. 가장 걸림돌이 된 것은 제가 이벤트 소싱과 CQRS의 개념..

안녕하세요. 항상 졸린 개발자 stark입니다!오늘은 DDD에서 도메인을 잘못 설계해서 비즈니스 로직이 꼬인 상황을 살펴보고 이 비즈니스 로직을 리팩토링 해봅시다.특히 개발자의 적인 화살표 if문을 어떻게 도메인 객체로 풀어나갈 수 있는지 알아봅시다.  잘못 사용 중인 도메인을 살펴보자.잘못된 도메인 사용 사례는 코드의 비효율성과 유지보수의 어려움을 야기할 수 있습니다. 예를 들어, 도메인 객체가 단순히 데이터를 담는 역할만 하고 비즈니스 로직이 모두 서비스 계층에 존재하는 경우, 객체지향의 장점을 충분히 활용하지 못하게 됩니다. 도메인은 비즈니스 로직을 포함하여야 함에도 불구하고, 단순히 상태를 저장하는 데이터 전달 객체(Data Transfer Object, DTO)로만 사용되면 코드의 응집도가 낮아..

스프링에서 도메인 객체를 사용하는 이유가 무엇일까?📌 서론이번 포스팅의 내용은 제가 "전통적인 3계층 아키텍처" 방식과 "DDD를 적용시킨 헥사고날 아키텍처"를 사용해서 개발해 보면서 느낀 점을 정리해 봤습니다. (특히 도메인 객체를 사용하는 이유와 객체 지향적인 개발에 중점을 두었습니다.) 제가 개발해 보며 느낀 점을 정리해 둔 것이기 때문에 잘못된 내용이나 잘 모르지만 아는 것처럼 적어둔 부분도 분명히 존재할 것이라고 생각합니다. 그러니 "단순한 개발 회고록" 정도로만 생각하고 재미있게 봐주시면 좋겠습니다 :) 1. 전통적인 3계층 아키텍처 방식의 개발 (도메인 객체가 없음)일반적으로 3계층 아키텍처에서는 도메인 객체를 사용하지 않는다.3계층 아키텍처에서는 대부분 Entity, Dto를 사용하는 방..

스프링에서 Data를 전달하는 객체에는 VO, DTO가 있는데 이게 어떤것인지 알아보자 VO (Value Object)와 DTO (Data Transfer Object)는 모두 Java 및 Spring과 같은 객체 지향 프로그래밍 및 프레임워크에서 데이터를 표현하고 전달하는 데 사용되는 설계 패턴이다. 1. VO, DTO의 차이점 (불변성) 1-1. VO(Value Object)의 불변성 VO는 '불변 객체'다. 한 번 생성되면, 그 상태를 바꿀 수 없다. 작고, 속성이 정해진 객체로, 생성 시에 모든 속성이 설정되고, 이후에는 바뀌지 않는다. 불변성은 VO의 중요한 특징이다. 이건 프로그램의 복잡성을 줄여주고 안정성을 높여준다. 1-2. DTO(Data Transfer Object)의 불변성 DTO는 ..