# DDD
[DDD] 도메인 주도 설계 철저 입문 정리 (2) - 지식 표현을 위한 패턴
이 글은 도메인 주도 설계에 대해 공부하기 위해 다음 책을 읽고 공부한 내용을 정리한 글입니다. 도메인 주도 설계 철저 입문 (나루세 마사노부 저/심효섭 역) Intro 이번 시간에는 도메인 지식을 표현하기 위한 패턴에 대해서 다뤄보려고 한다. 값 객체 (Value Object) 엔티티 (Entity) 도메인 서비스 (Domain Service) 값 객체 (Value Object) 값 객체란? 프로그래밍 언어에는 원시 데이터 타입이 있다. 이 원시 데이터 타입만 사용해 시스템을 개발할 수도 있지만, 때로는 시스템 특유의 값을 정의해야 할 때가 있다. 이러한 시스템 특유의 값을 표현하기 위해 정의하는 객체를 값 객체라고 한다. 값 객체의 예시 예를
도메인 이벤트와 전술적 설계
등장 개념 명령 객체: 데이터를 변경하는 액션을 요청할 때 필요한 객체 (ex. CreateProduct, UpdateProduct, DeleteProduct 등) 도메인 이벤트: 명령의 결과, 주목할 만한 무언가가 발생했음을 알리는 역할 (ex. ProductCreated, ProductUpdated, ProductDeleted 등) 이벤트 스토어: 도메인 이벤트들이 순차적으로 저장되는 저장소, 레코드 추가만 가능한 특징이 있음  - 도메인 주도 설계란?
Intro 평소에 '도메인 주도 설계' 라는 단어가 종종 언급되는 것을 보았다. 아직 DDD를 접해보지 않아 궁금했는데 막상 무엇부터 공부해야 할지 막막했다. 찾아보던 중 이 책이 입문자에게 적절할 것 같아 해당 책을 읽고 공부한 내용을 정리해보려고 한다. > 도메인 주도 설계 철저 입문 (나루세 마사노부 저/심효섭 역) 도메인 주도 설계란? 도메인 주도 설계란 말 그대로 도메인 지식에 초점을 맞춘 설계 기법이다. 도메인 그렇다면 도메인이란 무엇일까? 도메인이란 영역이라는 뜻이다. 소프트웨어 개발에서 말하는 도메인은 '프로그램이 쓰이는 대상 분야'라는
#1 도메인 주도 설계 첫걸음
도메인 주도 설계 방법론은 크게 두 가지 주요 부분으로 나눌 수 있다. 바로 전략적 설계와 전술적 설계다. >#### DDD의 전략적인 측면은 '무엇'과 '왜' 라는 질문에 대한 정답을 찾는 것이다. 즉 우리가 어떤 소프트웨어를 만드는지, 그리고 왜 그 소프트웨어를 만드는지에 대한 해답을 찾는 것이다. 다음으로 전술적 측면은 '어떻게?' 라는 방법에 대한 것이다. 즉, 소프트웨어 각각의 구성요소가 구현되는 방법을 찾는 것이다. 비즈니스 도메인이란? > 비즈니스 도메인은 기업의 주요 활동 영역을 정의한다. 일반적으로 말하자면 회사가 고객에게 제공하는 서비스를 말한다. 예를 들면 다음과 같다. 페덱스는 배송서비스를 전송한다. 스타벅스는 커피로 가장 잘 알려져 있다. 월마트는 가장 널리 알려진 소매업체 중 하나다. >기업은 여러 비즈니스 도메인을 운영할 수 있다. 회사가 비즈니스 도메인을 자주 변경할 수 있다는 점도 주목해야 한다.
SW 아키텍처 패턴 알아보기 #3 - 헥사고날 아키텍처
지난 시간엔 레이어드 아키텍처를 알아봤다. 이번에 소개할 아키텍처는 DDD의 대명사 헥사고날 아키텍처이다. 헥사고날 아키텍처란? DDD(Domain Driven Design)를 구현할 때 가장 자주 소개되는 아키텍처이다. 헥사고날 아키텍처의 핵심은 비즈니스 로직을 외부에서 격리하여 유지보수와 테스트를 쉽게 하는 것이다. 헥사고날 아키텍처 이미지 헥사고날 아키텍처의 구조는 domain, usecase, port, adapter로 나뉜다. usecase에서 domain과 port를 묶어 비즈니스 로직을 개발한다.(레이어드의 서비스 레이어) port는 interface로 adapter가 구현하게 되며, usecase에선 adapter가 변해도 상관 없도록 만들어준다. Port랑 Adapter는 뭐하
2장 - 아키텍처 개요
최범균님의 도메인 주도 개발 시작하기를 읽고 관련 내용과 느낀 점을 기록해 보려고 합니다! 네 개의 영역 표현 영역 사용자의 요청을 받아 응용 영역에 전달하고 응용 영역의 처리 결과를 사용자가 이해할 수 있는 형식으로 변환하여 응답한다. 
[설계 이야기] DDD 도입일지
딩동 Github 딩동 Behance > 디프만에서 딩동 프로젝트를 시작할 때 개발 생산성 향상을 위해 도메인 주도 설계(이하 DDD)를 도입헀다. 하지만, 충분한 사전 공부와 지식이 없는 상태에서 무작정 진행하다 보니 어려움을 겪었고 이를 계기로 확실하게 공부하고 실제 설계 과정을 통해 정리해보는 시간을 가져보려 한다. DDD란? > 도메인(현실세계에서 벌어지는 문제)을 중심에 놓고 설계하는 방식 => 즉, 서비스에서 다루는 도메인들끼리의 상호작용과 제약사항들을 중심으로 설계하는 방식이다. 전술적
1장 - 도메인 모델 시작하기
최범균님의 도메인 주도 개발 시작하기를 읽고 관련 내용과 느낀 점을 기록해 보려고 합니다! 도메인이란? 소프트웨어로 해결하고자 하는 문제 영역이다. ex) 온라인 서점, 주문, 결제 등 한 도메인은 다시 히위 도메인으로 나눌 수 있다. ex) 온라인 서점에 회원, 주문, 혜택, 배송 하위 도메인 도메인 전문가와 개발자 간 지식 공유
[도메인 주도 개발 시작하기] 2. 아키텍쳐 개요
아키텍쳐 개요 네 개의 영역 Layerd Architecture 표현, 응용, 도메인, 인프라스트럭쳐는 아키텍쳐를 설계할 때, 등장하는 전형적인 4가지 영역이다. 표현 계층은 컨트롤러가 위치하며, 사용자(웹 브라우저, 다른 서비스 등)의 요청을 받아 응용 계층에 전달하고, 전달받은 반환 값을 통해 사용자에 응답하는 역할을한다. 이 때, 응용 계층의 메서드의 호출 인자로 전달하는 역할을 수행하고, 메서드의 반환 값을 사용자가 원하는 형태(ex JSON)로 변환하여 전달하는 역할을 수행한다. 응용 계층은 서비스가 사용자에게 제공해야할 기능을 구현한다. 이러한 기능을 구현하기 위하여, 도메인 계층의 `도
MSA toy-project
MSA 와 DDD 의 차이 목표와 중점 MSA: MSA는 애플리케이션을 작은, 독립적인 마이크로서비스로 분할하고, 이러한 서비스 간의 통신을 통해 확장성, 유연성 및 빠른 개발/배포를 강조합니다. MSA는 주로 애플리케이션의 아키텍처 및 인프라스트럭처 측면에서 관심을 둡니다. DDD: DDD는 비즈니스 도메인 모델을 중심으로 소프트웨어를 설계하는 방법론으로, 비즈니스 도메인의 복잡성을 이해하고 그에 맞춰 소프트웨어를 구조화하는 것을 강조합니다. DDD는 주로 비즈니스 도메인 모델링 및 그 모델을 코드로 반영하는 데 중점을 둡니다. 범위 MSA: MSA는 애플리케이션의 아키텍처 레벨에서 작동하며, 서비스 간 통신 및 인프라스트럭처 관리와 관련이 있습니다. 이는 개발자, 운영팀 및 인프라 엔지니어에게 영향을 미칩니다. DDD: DDD는 비즈니스 도메인 모델링과 관련이 있으며, 주로 소프트웨어 개발자 및 비즈니스 전문가에게 영향을 미칩니다
[HanBitN MSA Season 1-2] 주니어 개발자를 위한 TPO for TDD 리뷰
주니어 개발자를 위한 TPO for TDD > 부제: 테스트는 필수! TDD는 상황에 따라! 한빛N MSA(Micro Seminar Assemble)는 한빛미디어 디지털콘텐츠개발연구소에서 준비한 세미나 시리즈다. 학교와, 학원 등에서 다루지는 않지만, 현업에서 일을 할 때 필요한 지식, 기술, 정보 등을 전달하는 걸 목표로 진행되는 세미나다. 각 세미나는 격주 목요일마다 진행되며(공휴일 제외), 홍대에서 세미나가 열려 접근성도 좋았다. 이번 세미나의 주제는 TDD. 정보람님의 "주니어 개발자를 위한 TPO for TDD" 세션을 듣고 일부 정리해봤다. > 게시글에 사용된 강의 자료는 한빛미디어의 지원을 받았습니다. 
MSA Phase 2. DDD
서론 MSA에서 DDD 패턴이 필요한 이유 MSA가 추구하는 방향성에는 밑과 같다. Strong Module Boundaries (명확한 모듈 경계) DDD(Domain Driven Design) 패턴에 바운디드 컨텍스트(Bounded Context)을 이용하여 서비스간 결합도를 낮출수 있다. Independent Deployment (독립적 배포) DDD(Domain Driven Design) 패턴에서 Domain별로 나누기에 독립적인 서비스 배포가 가능하다. Technology Diversity (기술 다양성) 위 방향성도 위에 1, 2번에서 말한 장점으로 얘기할 수 있다. 예를들어 service 단위로 다른 프레임 워크, 다른 언어를 사용해서 개발이 가능하다. 본론 DDD 패턴 정의 DDD의 주요 설계 원칙 
Spring DDD Architecture 기초
개발 방식에 따른 아키텍쳐 Transaction Script - 스프링 개발의 가장 기초적인 개발 방식 여기서 서비스 로직은 모든 비즈니스 결정을 내리는 로직을 가지고 있다 레포지토리에 직접적으로 접근하는 로직을 가지고 있다 모든 비즈니스 결정 로직이 집약되어 있어 과한 책임을 가지고 있다 
DDD Architecture 기초
도메인 주도 설계(Domain-Driven Design, DDD)는 소프트웨어 개발 분야에서 도메인 지향적인 개발 접근법을 의미한다. 이는 도메인의 복잡성을 관리하고 도메인 전문가와 개발자 사이의 커뮤니케이션을 촉진시키기 위한 디자인 기법들의 집합이다. 도메인 주도 설계의 핵심 아이디어는 도메인의 중심에 모델을 두고, 도메인
[도메인 주도 개발 시작하기] 1. 도메인 모델 시작하기
도메인이란? 도메인이 무엇이 의미하는지 먼저 이해하고 가야한다. 처음의 나로서는 그저, “비즈니스 영역의 관심사”, 혹은 “소프트웨어가 해결해야하는 문제 영역”이라고 생각이 된다. 개발자 입장에서의 도메인은 구현해야할 소프트웨어의 대상을 도메인이라고 하며, 이는 곧 기술적으로 해결해야할 문제의 영역이다. 몇몇의 책에서는 도메인 전문가가 존재하는 영역을 도메인이라고 정의하기도 한다. 즉, 개발하고자 하는 소프트웨어를 하나의 큰 도메인은 여러 하위 도메인으로 분리할 수 있으며 각 도메인은 독립적인 기능을 제공하기도 하고, 다른 도메인과 함께 하나의 완전한 기능을 제공하기도 한다. 그렇다고 해서, 특정 도메인이 요구하는 모든 기능을 직접 구현하는 것은 아니다. 때로는 외부의 기 구현된 시스템을 이용하기도 한다. 여러 하위 도메인을 어떻게 구성해야할 지에 대한 고민과 그의 결과는, 상황에 따라 달라지며, 이러한 상황을
애플리케이션에서 인증(Authentication) 과정은 응용 로직이다.
우리가 사용하는 대부분의 서비스에는 기본적으로 애플리케이션에 대한 권한이 있는 사용자인지 확인하는 인증절차가 있다. 그것이 어떤 기술을 기반으로 이루어지던 간에 (session, jwt ...) 대부분의 서비스를 개발할 때 꼭 포함된다. 나는 대개 그렇듯이 JWT를 많이 사용하였다. 스프링을 이용해서 개발할 때는 보통 Spring security를 통해서 구현하니 굳이 생각해볼 일이 없었는데, 다른 언어와 프레임워크 상에서 DDD와 클린 아키텍처에 충실하게 구현할 때, 이 인증 과정을 어떤 층위에서 구현할 지 고민을 많이 했다. 처음에는 로그인과 회원가입 절차 역시 하나의 도메인으로 설정했으니까 사용자 정보를 나타내는 도메인 모델에 JWT 등을 포함시켜 처리하려 했으나, 구현 기술을 도메인 모델에 담는 게 넌센스란 걸 곧 깨달았다. 그렇다고 스프링에서 처럼, 이것을 완전히 인프라스트럭처 층위에서 모두 처리하게 하는 것도 무언가 찝찝하다. 결국 Request에서 JWT를
도메인 주도 개발 시작하기2 - chapter2
chapter2 - 아키텍처 개요 엔티티 고유의 식별자를 갖는 객체 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다. 밸류 고유의 식별자를 갖지 않는 객체로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소나 구매 금액을 위한 금액과 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다. (밸류의 경우 불변으로 구현할 것을 권장하며 이 뜻은 엔티티의 밸류 값이 변경된다면 새로운 객체를 생성해서 처리해야 한다는 뜻이다.) 애그리거트 애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 주문과 관련된 Order 엔티티, Orderline밸류, Orderer밸류 객체를 '주문'애그리거트로 묶을 수 있다. (일종의 군집화로써 개별 객체가 아닌 관련 객체를 묶어서 객체 군집
[DDD] Repository
애그리거트 애그리거트는 하나의 Root Entity와, 엔티티와 관련된 정보를 포함하는 Value Object들로 구성된다. 예로, Mebmer의 경우 root 엔티티는 Member의 이름, id, password 등으로 구성되며 Address와 같이 부가적이지만 많은 정보를 포함하는 것은 Value Object로 따로 빼서 관리한다. 외부에서는 entity 내의 value object에 직접 접근할 수 없으며 value object의 데이터를 이용하거나 변경하는 경우 반드시 root entity를 통해햐 한다. 그렇게 해야 root entity가 모르게 value object가 별개로 변경되는 일이 없고 필요한 도메인 규칙을 일관되게 적용하며 데이터를 변경하거나 읽을 수 있기 때문이다. > 애그리거트와 Repository 하나의 Member 당 여러 개의 Address를 저장하거나, Address처럼 여러 개의 필드(컬럼)를 갖는 경우, Member와 Address를