Easy Understanding

지금까지 DDD 설명에서는 도메인이라든지 바운디드 컨텍스트라든지 개념적인 것들을 다뤘다면, 이제부턴 실전 코딩이다. 데이터 중심의 개발에서 DB에 대응하는 Class들을 만들었던 것처럼, Domain에 대응하는 Class들을 만드는 과정이 필요하다. 이제부터는 각 도메인들을 Class로 표현해보기 위한 개념과 코드를 구경할 차례다. 1. 엔터티(Entity) @Entity public class Movie { @Id private Long id; private String name; private Long playTimestamp; private String directorName; ... public void changeMovieName(){ ... } public void fireAndHireNewD..

도메인과 바운디드 컨텍스트는 무엇이길래 이전 글에서도 이야기 했지만, DDD는 용어부터가 우리가 알고있는 것과 다르고, 익숙해져야 할 것들이 많다. 특히나 바운디드 컨텍스트(Bounded Context)에 대해서는 초반에 감이 잘 오지 않았던 것 같다. 시작전에 간단하게 요약을 해보자면, DDD는 전략적(Strategic) 설계와 전술적(Tactical) 설계로 나뉜다. - 전략적 설계: 개념적으로 도메인과 바운디드 컨텍스트를 정의하고, 유비쿼터스 용어를 정리하는 부분 - 전술적 설계: 세부 아키텍처와 코드의 구현과 관련된 부분 이라고 보면 되는데, 이 글에서 다루는 것이 전략적 설계의 핵심적인 부분이라고 보면 된다. 조금씩 다르지만 대략적으로 아래의 순서로 전략적 설계가 진행된다고 보면 된다. 1. 도..

참고로 스터디는 다음의 책을 통해서 진행했다. DDD 간단 소개 우선 DDD(Domain-Driven Design)에 대해서 간단하게 소개를 하자면 다음과 같다. DDD는 단순한 코딩/아키텍처 구성 방법이 아니다. 즉 패턴과 설계와 아키텍처를 모조리 합친 그 무언가 개발의 새로운 패러다임이다. DDD는 기존의 설계 방식과 개발 방식을 새로운 관점으로 보게 해준다. 개발을 하면서 부딪히는 문제는 여러 가지가 있지만 크게 두 가지로 나눌 수 있다. 사용자(고객, 회사 등)에서 제시하는 복잡하고 자주 변화하는 요구사항 성능이나 협업에서 발생하는 기술적인 어려움 DDD는 보통 첫 번째 원인 해결에 초점을 맞춘 방법론이다. 기획자(도메인 전문가)들의 요구사항을 개발 언어로 변환하는 '비효율'을 최대한 '효율'적으..