※ 고등학생이기 때문에 주변에 이 분야에 실력있는 사람이 없을 뿐더러 공부를 하는 사람도 없기에 구글링과 도서에 의존합니다. 출처는 꼭 밝힙니다. 제가 공부한 것을 작성하기 때문에 틀린 부분도 있을 수 있습니다. 지적해주시면 감사합니다.
DDD 란 Domain-Driven-Design 이라는 개발 방법론입니다. 저는 이 DDD 라는 개발 방법론을 이번 쎄트렉아이 인턴으로 생활하면서 프로젝트를 DDD 개발 방법론으로 진행을 하기 때문에 구글링과 사수님의 도움으로 무척 얕게 공부를 하게되었습니다.
DDD 개발 방법론은 무척이나 이해하기 힘들고 제대로 적용하기 힘들다고 해서 앞으로의 프로젝트는 이 DDD 개발 방법론을 이용해서 프로젝트를 진행할 계획입니다.
Domain Driven Design 을 이 글에서는 줄여서 DDD라고 부르겠습니다.
도메인 주도 개발은 Eric Evans 가 출간한 Domain Driven Design 이라는 책으로 처음 소개한 소프트웨어 개발 방법론이다.
이 DDD는 도메인 전문가와 개발자 사이의 의사소통이 어려움은 도메인 컨셉의 Ubiquitous Language 라는 보편적인 언어로 표현하는 것을 목표로 하는데 이 도메인 모델은 이 보편언어의 뿌리, 중심을 제공하고 팀 내의 의사소통, 그리고 구현까지 연결할 수 있도록 하는데 이렇게 하려면 사용하는 언어에 대한 이해가 팀원간 일치해야 하는데 그렇지 않은 경우 모델 변경 및 코드에서는 Refactoring으로 이어지는 과정이 나타난다.
보편언어들로 정의할 때 고려되어야 하는 것은 Bounded Context(제한 영역) 범위 내에서 정의해야 한다는 것인데 Bounded Context는 독립적으로 서비스 될때 문제없는 업무 범위로 생각할 수 있다. 이런 언어는 주로 업무위주의 언어를 사용하는 것이 좋은데 일반적으로 용어사전 형태로 구성하는 것이 좋으며 구성원 누구나 쉽게 참조할 수 있도록 해야 한다.
여기서 주의할 점은 용어 사전 형태로 구성한다고 해서 프로젝트를 진행하기 시작했을 때부터 모든 용어들을 백과사전처럼 정의해서 진행하는 것은 불가능하다고 하는데 DDD는 폭포수 개발 방식보다는 애자일 개발 방식(블로그 어딘가에 정리해 놓음)과 같은 반복 수행을 통해 완성도를 높이는 Model Exploration Whirlpool(모델 개발 소용돌이) 방식을 대부분 채택하고 있다.
도메인에 관련된 핵심 업무 관련 model에 대한 용어부터 정의하고 이 model에 대한 이해도를 팀원간 이해도를 높이며 발전시키는것이 중요하다고 한다.
[인턴 생활을 하면서 사수님께 들었던 이야기는 DDD 개발 방법론으로 프로젝트를 진행하는 이유가 나중에 유지보수가 쉽고 변경하기 쉽다고 사용하신다고 하셨었던 것 같습니다.]
먼저 Layered Architecture 에 관련된 요소들에 대해서는 다음과 같다.
User Interface : 사용자에게 정보 출력
: 시용자의 요청을 해석, 하위 레이어에 전달
[이번 프로젝트에 적용할 때는 UI에 대한 내용이 들어갈 것 같다. (아직 구현 시작도 안함)]
Application : 어플리케이션 상태를 관리한다.
: 비지니스 로직/객체 상태를 포함하지 않고 실제 비지니스 처리는 도메인에 요청한다.
[이번 프로젝트에 적용할 때는 Application 패키지에 기능들을 호출?을 했다. (메소드 호출) ]
Domain : 도메인에 대한 정보를 포함한다.
: 비지니스 객체의 상태를 포함한다.
: 비지니스 로직을 제공한다.
[이번에 프로젝트에 적용할 때는 Domain 패키지에 Interface를 정의했다.]
Infrastructure : 다른 레이어를 위한 지원 라이브러리
: 영속성 구현
[Infrastructure 패키지에는 Interface에 대한 기능들을 구현했다.]
도메인 모델 정의시 몇 가지 구현 패턴이 있는데 기본적으로 사용되는 패턴은 Entity 기반 모델을 정의하는 패턴을 사용한다. 이 기본 패턴에서 정의되는 요소는 다음과 같다.
Entity : 모델을 표현하며 고유의 식별 값을 가진다. 그리고 모델과 관련된 비지니스 로직을 수행하며 자신만의 라이프 사이클을 가진다.
[내 생각으로는 고유의 식별 값을 가지니까 객체? 라고 할 수도 있을 것 같다.]
Value : 고유의 키 값을 갖지 않으며 데이터를 표현하기 위한 용도로 주로 사용한다. 즉 개념적으로 완전한 데이터의 집합이며 Entity에 속성으로 사용된다. 그리고 Entity 와는 다르게 자신의 라이프사이클을 갖지 않는다.
[그냥 Value Object랑 비슷하게 생각하면 될 것 같기도 한다. ]
Aggregate : 관련된 객체들의 묶음이다. Aggregate는 데이터 변경시 한 단위로 처리 되며 각각의 Aggregate 마다 경계를 가진다. 이 Aggregate의 필요성으론 많은 도메인 모델을 가능한 간단하고 이해가능한 수준으로 만들 필요성과 연관의 개수를 줄임으로써 복잡도가 감소된단 것이 있다.
[음...이것은 DB에서 ER 다이어그램이란 것이 생각나게 만드는 것 같다. 그니까 예시를 들면 쇼핑몰 - 판매자 - 상품, 뭐 이런 식?]
Repository : Entity 를 보관하는 장소이며 기본 규칙으로 Aggregate 당 한 개의 Repository 인터페이스가 있어야 하며 Aggregate의 CRUD 기본 단위는 루트이다. Repository의 기본 인터페이스로는 save(루트), List<루트>, delete(루트)가 있다.
[쉽게 Entity 를 보관하는 장소라고 생각하자...]
Service : 한 Entity나 Aggregate에 속하지 않은 도메인 기능을 도메인 서비스로 불리하는 것이다 또한 도메인 서비스를 구현하고 타 레이어 서비스와 구분한다.
[음..예를 들게 된 것이 계좌 이첸데 계좌 이체는 한 계좌 Entity 객체가 수행할 수 없는 도메인 기능인 것이 예라고 한다.]
[아직 나도 이해를 잘 하지 못한 것이라서 앞으로 많은 자료들과 프로젝트를 진행하면서 감을 익혀야할 것 같다. 그래도 나한테는 3주동안 사수님이 계시니 모르는 것을 여쭤보아야 할 것 같다.]