-디디디!!!란 도메인 주도 설계 이론 즉, DDD를 말한다.

-DDD : Domain Driven Design이라고 불린다. 이는 도메인을 우선적으로 설계를 시작하는 것을 말한다.

DDD

DDD에 대해서

-Eric Evans가 2003년에 만들었다.

-새로운 개발 / 설계 개념에 많은 영향을 끼쳤다.

-특정 디자인 패턴이 보다 잘 활용될 수 있는 토대를 제공하였다.

1-Domain Modeling

-도메인 지식과 1:1로 매칭되는 코드 구조

-모든 협력자들이 구조 설계에 참여할 수 있다.

-코드에 매치되는 도메인에 변경이 생길경우 , 코드 또한 변경이 수반되어야 한다.

-DDD는 비즈리스가 확장 될 때마다 똔느 문제가 발생할 때마다 진화해 나가는 형태로서 DDD를 박아놓고 UI Layer와 Data Layer를 붙혀주는 것이다.

사용자 스토리

-짧은 이야기여야 하고 몇 문장으로 구성되야된다. : 포스트잇에 들어갈 수 있는 길이

-사용자가 Domain 중심의 결과가 도출되는 작업을 하는 것을 기술하여야 하고 사용자의 시나리오에 대한 설명이 들어가야한다.

-CUJ(Critical User Journey)라고 불리는 사용자 스토리를 모든 구성원들이 모든 상황에서 가장 우선적으로 고려한다.

-작성방법

• [동기/목표달성]을 하기 위하여,
• [사용자 / 역할 / 페르소나]로서 나는,
• [요구 / 달성]을 하고 싶다.

-첫 동기/목표가 매우 중요하다.

• 그에 따라 어떻게 개발팀이 문제를 이해하고 , 스토리를 구현할 것인가가 결정되기 때문이다.

2-Bounded Context

-하나의 모델만으로 도메인을 설명 할 수 없어서 수직으로 구분한다.

-Bounded Context는 비즈니스들 사이의 자연스러운 구분을 가능하게 한다.

-동일한 용어도 Bounded Context에 따라서 다른 의미를 지닐 수 있다.

-DDD는 코드를 잘 정의된 경계선으로 구분해서 조직되도록 돕느다.

3-Entities

-엔티티는 기본적으로 ID에 의해 정의된다. 모든 엔티티는 ID에 의해 구분된다.

-형태가 아닌 행위를 다룬다.

-Entity는 시간이 지나도 동일한 엔티티로 인식된다. 상태값이 변경되어오 식별자가 있으니까 같은 엔티티는 같은 엑티티로 식별된다.

-Entity는 형태가 아니라 행위를 나누는 도면에서 사용되는 것이다.

도메인 엔티티 설계에서 주의할 사항들

-저장소 , 저장 방법 등은 일단 무시한다. 자세한 구현사항 이런 것들은 전부 다 생략하고 비즈니스에서 해결하거나 추구하는 문제점들에만 집중하면 된다.

-그러니까 그냥 사용자한테 보여주는 것, 어떻게 보여줄가에 대한 것 이런것들은 그냥 다 무시하고 비즈니르로직에 집중해서 설계를 하는 것이다.

UI / Domain / Data 계층이 각각 갖는 엔티티

-똑같은 엔티티여도 계층마다 불러지는 이름이 다르다. 예를들어 User라는 엔티티가 있을 때 UI 계층에선느 UserModel로 도메인 계층에서는 USer로 데이터 계층에서는 UserEntity라고 불린다.

-원칙적으로는 데이터 계층의 엔티티와 도메인 계층의 엔티티가 같을 것으로 생각하면 안되고 서로의 데이터에 대해 의존이 생기면 데이터 스키마 변경 시 양쪽을 다 고쳐야 한다.