-DDD를 실제로 해보는 방법은 다음과 같다.

1.DDD : 말그대로 DDD를 실제로 구현하는것

사용하는 경우

복잡한 트랜잭션(최소한의 로직 단위)이 들어가는 앱

-복잡한 트랜잭션이 앱 내부에 들어가는 경우를 말한다. DDD를 사용하면 복잡성을 다룰 수 있고 모델링하는데 도움이 되도록 만든 것이므로 비즈니스 적인 요구사항에 알맞게 코들르 작성 할 수 있다.

복잡한 도메인 문제가 들어가는 앱

-앱의 서버상에서 복잡한 로직이 들어가는 경우를 말한다. 이때는 웬만하면 필수적으로 도메인을 모델링하고 구현해야 하는데 이때 DDD를 사용하면 아주 편리하다.

아무 것도 없이 처음 프로젝트를 들어가는 경우(green field project)

-새로운 프로젝트를 시작할 때 , 처음부터 도메인 중심의 설계를 시작하면 초기 단계에서 복잡한 트랜잭션들을 관리하고 유지보수하기에 편리한 구조를 만들어서 시작 할 수 있기 때문에 DDD를 통해서 프로젝트의 방향성을 명확하게 하고 초기 설계단에서부터 도메인의 복잡성을 해결 할 수 있기 때문에 편리하다.

DDD를 사용하기 어려운 경우

DDD를 경험해 본적이 없는 경우

-DDD는 복잡한 Domain 관련문제들을 해결하기 위한 설계 접근 방식이다. 경험이 없는 팀이 없다면 도메인 설계의 복잡성을 적절히 구현하기 힘들 수 도 있다.

잘만들어진 Ui Layer가 없는 경우

-DDD는 UI 레이어와 명확한 분리를 추구하는데 UI Layer가 잘 구성되지 않는다면 UI Layer와 Domain Layer가 서로 결합도가 높아진다면 굳이..? 할 필요가 없다.

Legacy Data Layer를 기반으로 Domain Model을 구현해야 하는 경우

-이 또한 위의 내용과 비슷하게 굳이 DDD를 활용한 설계를 할 필요가 없다.

Data를 CURD로만 충분히 다룰 수 있는 경우

-아주 단순한 CURE(Create , Read , Update , Delete) 4개의 기능만으로 데이터를 충분히 다룰 수 있는 도메인이라면 DDD를 적용하는 것은 너무 오버하는 것이다. DDD는 복잡한 비즈니스 로직과 규칙을 가진 도메인 영역을 다루기 위한 것이다.

2.DDD Lite : DDD가 싫어하는 것들 모임

Transaction Script 형태의 구현

-상태가 없고 UseCase 클래스로 구현하는 것을 말한다. invoke 메서드를 활용해서 구현을 하면 나중에 구현을 할 때 함수이름을 작성하지 않아도 그냥 클래스 옆에 괄호만 치면 실행하는 것이 가능해서 이런식으로 구현하는 것을 말한다.

사용하면 좋은 경우

-특정 로직에 대해서 어렵게 만들어서 정의하고 하는 것들이 나중에 확장성도 어렵고 재활용도 어려운 여러 가지 문제가 생길 수 있기 때문에 비추한다. 하지만 개별적인 복잡한 트랜잭션이 있는데 해당 트랜잭션의 갯수가 많지 않고 각각의 Use Case들의 연관성이 떨어져서 독립적으로 존재할 수 있다면 DDD Lite를 개추한다.

3.No-Domain Layer : 도메인으로 분류되지 않는 제 3의 계층 : 제3계층

Domain으로 분류되지 않는 계층을 구현

데이터 조작이 단순한 경우

-단순한 CRUD(Create, Read, Update, Delete) 작업이나 간단한 데이터 변환 과정이 필요한 경우, 도메인 레이어를 별도로 구현하기보다는 위에서 말하는 3번의 계층에서 처리하는 것이 더 좋다. 이렇게 하면 앱 내부의 코드들의 복잡성을 줄이고 개발 속도를 높일 수 있다.

데이터 계층에서 얻은 엔티티를 UI의 State 또는 UI State로 가공되기 위한 중간 단계로 변환하는 역할이 중요한 경우

-위에서 말하는 3번의 계층은 데이터 계층에서 가져온 엔티티를 UI에서 사용할 수 있는 형태로 변환하는 중간 처리 역할을 할 수 있다. 이렇게 하면 UI에서 편리하게 사용 할 수 있어서 좋다.

뷰모델에서 중복되는 재사용되는 코드들이 Service 형태로 분리시키는것이 유리한 경우

-뷰모델 내에서 반복되는 로직들인데 아무리 봐도 UI계층 코드가 아니고 비즈니스 로직에 해당되는 코드 같으면 3번 계층에 Service 형태로 분리하여 관리함하면 코드의 중복을 줄일 수 있고 , 유지보수성을 향상시킬 수 있기 때문에 앱의 로직들을 관리하기 편하다.

DDD 전술패턴 : 값 객체(Value Objects)

Id X && 값으로 객체를 구별

-기본적인 엔티티가 ID를 갖고 있는 것과는 다르게 ID가 존재하지 않고 값 자체가 그냥 하나의 오브젝트 인스턴스가 대변하고 있는것이다. 따라서 인스턴스의 hash 값으로 객체가 구분되는게 아니라 값이 구별 기준이 되는 것을 말한다.

Immutable

-값이 인스턴스 구분의 기준이니까 당연히 불변해야 한다.

다른 인스턴스라도 값이 같으면 같은 객체임

-갖고 있는 값이 구분 기준이니까 값이 같아? 그럼 너네 둘은 같은 놈들이야.

값객체 적용방법

값들이 명확한 의미를 가지도록 해야한다.

-DDD에서는 값객체가 겁나리 중요한데 왜냐하면 도메인을 위한 값들이 명확한 의미를 가지는것이 유리하기 때문이다. 그러면 굳이 이게 무엇을 의미하는지 궁금해서 찾아볼 필요 없음 개꿀 ㅋ

값객체가 필요한 이유 + 장점

타입이 사실상 뭔지 알려주는 역할도 같이함

-예를들어 String을 Name , Address.. 이런식으로 표현하면 개발할 때 편하다. 그리고 내가 만약에 실수했으면 안드로이드스튜디오가 컴파일 할 때 찾을 수 도 있어서 개꿀 ㅋ

불변성이니까

-값 객체는 불변성이니까 상태 변경 체크에 유리하다. 왜냐면은 값 객체는 다른 객체로 교체된 여부만 판단하면 되니까 좋다.

만드는 방법

Inline class : 조금 제한적임

Primitive type(숫자,문자,논리)을 감싸기 위한 클래스임

-@JvmInline 어노테이션을 활용해서 value class로 만들어 주면된다.

@JvmInline
value class Day(private val day : Int) {

	init {
    	require(day >= 0)

	}
    companion object {
    	val Int.days : Day
        	get() = Day(this)       
    }
}

하나의 필드만 허용한다. value object 구현을 위해서는 부족하다.