안녕하세요. 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를 사용하는 방..