시작하며안녕하세요. 개발자 stark입니다.최근 제가 현업에서 테스트 코드 작성과 코드 리팩토링을 진행하며 느낀 점들이 굉장히 많습니다. 이전에 프로젝트를 구성했을 때는 비즈니스에서 요구하는 기능을 구현하는 것과 기술적으로 어떤 것을 사용하는 것이 좋을지에 대해 집중했었던 것과 달리 이번 기회에 개발이란 무엇인가에 대해서 정말 많은 고민을 하게 되었고 저 스스로는 어떤 생각을 하며 개발을 해왔는지도 정리할 수 있게 되었습니다. 그래서 이번 포스팅에서는 제가 한 생각들을 조금 회고해보려고 합니다. 완전 개인적인 생각이니 이런 생각도 있구나 하며 재미있게 봐주세요 ㅎㅎ 추상화는 정말 중요하다저에게 추상화는 너무 어렵습니다. 클래스나 메서드 이름을 작명할 때 추상화를 적용하게 되는 경우가 많은데 제가 만든 ..

시작하며안녕하세요. 개발자 stark입니다.오늘은 제가 도메인 주도 설계(DDD)를 하며 Aggregate를 구성할 때 느낀 점을 정리해보려고 합니다. 저는 실무에서도 사이드 프로젝트에서도 DDD로 개발을 진행하고 있습니다. 그런데 도메인에 대한 Aggregate를 구성할 때 매번 하고 있는 고민이 있습니다. 예를 들어 사이드 프로젝트에서 Aggregate Root가 될 PostEntity와 일반 종속 Entity(첨부파일, 해시태그)들을 포함하는 게시글 Aggregate를 하나 구성했습니다. 저는 Spring과 DB접근 라이브러리로 ORM인 JPA를 사용하고 있었기에 엔티티의 관계성을 설정해 줄 필요성이 있었습니다. 근데 여기서 Aggregate Root인 PostEntity만으로 Repository..

시작하며안녕하세요, 개발자 stark입니다! 오랜만에 글을 적게 되었는데요. 오늘은 제가 실무에서 가장 많이 고민했던 주제 중 하나인 DDD(Domain-Driven Design)의 애그리게잇 설계에 대해 다뤄보려고 합니다. 특히 Spring과 Java 환경에서 이를 어떻게 효과적으로 구현할 수 있는지, 실제 경험을 바탕으로 공유해 드리겠습니다. 애그리게잇은 DDD에서 가장 핵심적인 개념임에도 불구하고 이를 적절히 설계하는 데 어려움을 겪습니다. 저 같은 경우에는 매번 로직을  작성하면서 "이 엔티티는 어느 애그리게잇에 속해야 할까?", "애그리게잇 경계를 어디까지 설정해야 할까?" 등의 고민이 끊이지 않았습니다. 그래서 오늘은 최대한 실용적인 관점에서 접근해 보겠습니다.  도메인 주도 설계와 애그리게잇..

안녕하세요. 2025년을 준비 중인 개발자 stark입니다! 이번 포스팅에서는 '유비쿼터스 언어'에 대해 설명드리고자 합니다. 이 포스팅은 유비쿼터스 언어를 사용하는 DDD(Domain-Driven Design)에 대해 이해를 하고 오셨다고 가정하고 글이 작성되었습니다. 그래도 혹시 모르니 정말 간단히 설명드리자면 DDD는 '복잡한 도메인 문제'를 해결하기 위한 '설계 철학'으로, 개발팀과 비즈니스 팀 간의 긴밀한 협업을 강조합니다. 그 핵심 요소 중 하나가 바로 유비쿼터스 언어(Ubiquitous Language)입니다.  1. DDD에서 유비쿼터스 언어가 필요한 이유유비쿼터스 언어는 팀원들의 '협업'과 '의사소통'의 중심이 됩니다.소프트웨어 개발 과정에서 가장 흔한 문제 중 하나는 도메인 전문가와 개..

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

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