시작하며안녕하세요! 개발자 Stark입니다. 최근 OpenAI, Google, xAI, Meta와 같은 글로벌 기업들은 마치 혁신의 경쟁이라도 하듯 강력하고 진보된 AI 모델을 앞다퉈 출시하고 있습니다. AI 기술의 발전은 마치 2000년대 초 스마트폰이 등장했을 때와 비슷합니다. 그 당시 많은 사람들은 작은 손바닥 위 기기가 우리의 생활 전체를 바꿔 놓으리라 상상하지 못했습니다. 그러나 스마트폰은 순식간에 우리의 일상을 완전히 뒤집어놓았습니다. AI 역시 그러한 변화의 중심에 서 있다고 생각합니다. 초창기 ChatGPT의 등장만으로도 놀랐던 우리는, 불과 몇 년 만에 압도적으로 높아진 성능과 저렴한 비용으로 인해 누구나 쉽게 AI를 활용할 수 있는 시대를 맞이하게 되었습니다. 저는 이러한 변화가 우리 ..

시작하며안녕하세요. 개발자 Stark입니다.제가 최근 MSA 프로젝트를 운영하다 보니 서버 간 트랜잭션을 한눈에 볼 수 있도록 도와주는 분산추적 도구가 정말 중요하다는 생각을 하게 되었습니다. 예전에 제가 사이드 프로젝트를 할 때 Zipkin을 활용하여 분산추적을 구현해 봤었는데 최근 제가 트렌드를 알아봤더니 Jaeger를 사용하는 것이 조금 더 클라우드 네이티브 환경에 잘 맞는다는 것을 알게 되었습니다. 그래서 이번 기회에 실무 프로젝트에도 적용해 볼 겸 공식 가이드도 계속 살펴보고 AI 검색(ChatGPT Deep Research)의 도움을 받아 내용을 정리해봤습니다. 참고로 내용은 제가 구축하려는 방향성인 Jaeger(v2) + Elasticsearch를 기준으로 설명되었습니다. 잘못된 정보가 있을..

시작하며 : 왜 전략적 설계가 필요한가?프로젝트 초기에는 모든 기능이 하나의 코드베이스 안에서 개발됩니다. 이때는 기능이 적어 구조가 단순하고 개발 속도도 빠릅니다. 하지만 프로젝트가 성장하면서 기능들이 점점 많아지면, 필연적으로 코드 간의 의존성이 복잡해지기 시작합니다. 예를 들어, '주문' 관련 코드가 '회원'의 등급 정보를 참조하고, '배송' 코드가 다시 '주문'의 상태를 변경하는 등, 각기 다른 기능들이 서로의 내부 로직을 침범하며 뒤죽박죽 얽히게 됩니다. 결국 개발자 한 명이 작은 기능을 하나 수정하기 위해 시스템 전체의 맥락을 파악해야 하는 상황이 오고, 이는 개발 속도를 저하시키고 예측 불가능한 버그를 만들어내는 직접적인 원인이 됩니다. 전략적 설계는 바로 이러한 '의존성의 폭발' 문제를 해..

시작하며안녕하세요. 개발자 stark입니다.최근 DDD관련 책을 읽다가 이런 문구를 봤습니다. "모든 기술적 관심사로부터 비즈니스 로직을 분리하는 것이 포트 앤 어댑터 아키텍처(헥사고날 아키텍처)의 목적이라서 DDD의 비즈니스 로직 구현에 매우 적합하다." 저는 지금 실무에서 헥사고날 + DDD로 개발을 진행하고 있다 보니 이 조합이 비즈니스 로직을 구현하기에 매우 적합하다는 것에는 공감을 했습니다. 근데 스스로에게 "그래서 이게 왜 적합한데?"라고 질문해 봤더니 아무리 생각해도 답이 나오지 않았습니다. 당연히 그럴 수밖에 없었던 게 저는 지금까지 이게 왜 적합한지에 대해서는 단 한 번도 생각해 본 적이 없었던 것입니다. 그냥 적합하다고 하니 "MSA + DDD = 헥사고날 아키텍처" 이렇게 생각하고 사..

시작하며안녕하세요. 개발자 Stark입니다.이번 글의 주제는 도메인 주도 설계(Domain-Driven Design, DDD)를 적용하다 보면 마주치는 중요한 결정 중 하나인 '어떻게 다른 애그리거트(Aggregate)를 참조할 것인가?'입니다. 많은 DDD 전문가들이 작성한 책과 글을 보다 보면 "애그리거트 내부에서는 다른 애그리거트를 ID를 통해 참조하라"라고 조언합니다. 여기서 드는 궁금증은 왜 객체 직접 참조가 아닌 ID 참조를 권장하는 걸까요? 지금부터 그 이유를 명확한 경계 설정과 트랜잭션 관리라는 두 가지 핵심 축을 중심으로 알아봅시다. 애그리거트와 그 경계의 중요성먼저 애그리거트가 무엇인지 간단히 짚고 넘어가겠습니다. 애그리거트(Aggregate)는 쉽게 말해 관련된 데이터와 기능을 하나..

시작하며안녕하세요 개발자 stark입니다.최근 제가 업무 중에 선배님과 애그리거트(Aggregate) 설계에 대한 토의를 하던 중 VO에 대해서 많은 얘기가 오갔습니다. 저희는 어떤 시점에 VO를 어떻게 사용하는 것이 적절한지 얘기를 나누었습니다. 우선 식별자를 통해 값을 구별할 필요가 없다는 것부터 시작해서 VO안에 비즈니스를 담을 수 있고 불변의 장점이 있다는 것까지 얘기가 진행되었습니다. 그런데 얘기를 다 하고 나서 생각해 보니 무언가 핵심을 놓친 것만 같았습니다. 그게 무엇인가 했더니 VO를 어떻게(how) 사용하는지는 알고있는데 왜(why) 사용하는지는 모르고 있었기에 핵심 개념에 대해서는 하나도 얘기를 하지 않았던 것입니다. 그래서 바로 블라드 코노노프가 지은 '도메인 주도 설계 첫걸음'이라는..

시작하며안녕하세요. 개발자 stark입니다!오늘은 제가 헥사고날 아키텍처를 하면서 항상 고민하던 것을 정리해 봤습니다. 그 내용은 바로 in/out port 인터페이스 메서드 시그니처를 작성할 때 매개변수로 dto, 도메인, 기본 타입 중에 어떤 것이 가장 적절한가?입니다. 저는 여러 타입의 매개변수를 다 적용해 봤는데도 어떤 것을 써야 할지 감이 제대로 잡히지 않았는데 이번 기회에 다시 분석하고 정리하며 제 나름의 기준점을 잡았고 그 내용을 적어봤습니다. 이번에는 제가 겪은 과정 자체를 맛있게 담지는 못했지만 결론은 담아두었으니 다들 재미있게 봐주셨으면 좋겠습니다. Let's go! In port(UseCase)의 매개변수는 DTO보다 Command헥사고날 아키텍처에서는 애플리케이션의 각 계층이 자기..

시작하며안녕하세요. 개발자 stark입니다. 테이블을 설계하다 보면 비슷한 개념을 가지는 데이터 모델을 타입 컬럼을 사용해서 분류하고 같은 테이블을 사용하도록 하는 경우가 흔합니다. DDD에서는 이런 식으로 설계된 테이블 모델(Entity)과 도메인 모델(Aggregate)의 개념을 동일하게 적용하면 도메인 모델 내부에 여러 타입의 비즈니스가 쌓이면서 점점 혼잡하고 복잡해지면서 'God Object' 문제가 발생합니다. 저는 실제로 이런 문제를 마주하며 '도메인 모델(Aggregate)을 테이블 모델과 동일시 하는 게 정답일까?'에 대해 매번 고민해 왔습니다. 그리고 이제 생각이 정리되어 이번 포스팅을 작성하게 되었습니다. 포스팅에서는 내용 이해를 위해 'documents(문서)'라는 가상의 테이블을 통..

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