아무런 리소스 및 레퍼런스 없이 개발을 하는 프로젝트를 GreenField Project라고 한다. GreenField Project를 시작할 때 무엇을 먼저 하는 것이 좋을까?
가장 중요하고, 잘 변하지 않는 부분부터 공략한다. 기획자 혹은 비즈니스 부서와 함께 핵심 사용자의 시나리오를 설정하고, 핵심시나리오를 따라 코드를 옮겨 적는다. 이 때 최대한 데이터 및 UI와 같은 가변적인 요소는 배제하고, 애플리케이션의 핵심 로직, 재사용이 가능한 로직을 먼저 구현한다.
1. Domain Layer
도메인 계층은 Ui 계층에서 사용되는 비즈니스 로직을 캡슐화하여 모아놓은 곳이다. 인터페이스 형태로 존재하며, 실제 구현체는 숨겨져 있는 곳이다. 기획자 및 비개발군이 볼 수 있는 계층이며, 실제 비즈니스 로직이 담겨 있다.
도메인 계층이 왜 필요할까?
- 책임에 따라 UI 계층이 바라보는 액터와 데이터 계층이 바라보는 액터가 다르며, 이를 중간에서 매개체 역할을 한다.
- 비즈니스 규칙이 변경되어도, 다른 계층에 최대한 영향을 미치지 않게 하기 위함이며, 최대한 각 계층이 독립적인 구성을 가질 수 있도록 한다.
- 독립적인 구성을 통해 테스트 가능성을 확대하며, 비즈니스 룰만 격리하여 테스트가 가능하게 한다.
도메인 계층은 무엇을 할까?
- 도메인 비즈니스 로직을 수행 : (UI, 데이터 계층과도 독립적인 비즈니스 로직)
- 데이터의 변환 : 데이터에서 받은 엔티티를 앱에서 의미있는 형태로 변환
- 코드 중복 제거 : UI 계층에서 중복으로 사용되는 공통 로직을 유스케이스 형태로 설계
DDD(Domain - Driven Design, 도메인 주도 설계)
프로세스에 대한 깊은 지식을 담고 있는 도메인 모델과 도메인 규칙들의 개발을 중심으로 놓는 개발 방법이다. DDD는 불변하는 도메인을 올바르고 효율적으로 설계하는 방법과 UI와 데이터 계층을 연결할 수 있는 방법을 기술하고 있다. 비즈니스 문제를 해결하기 위한 접근 방식으로, 사고방식 및 커뮤니케이션 방법, 소프트웨어 패턴, 코딩 가이드를 포함한다.
도메인 모델링 : 도메인에 맞게 추상화하는 과정
- 도메인 지식과 1 : 1로 매치되는 코드 구조로, 모든 협력자들이 구조 설계에 참여한다.
- 코드에 매치되는 도메인 변경이 생길 경우, 코드도 변경되어야 한다.
- 핵심 문제를 해결하고, 추가적인 내용을 붙여나가는 식으로 구성하여, 비즈니스와 함께 성장하도록 구현한다.
도메인 계층을 구성하는 방법
1. DDD : 도메인 지식의 구현
- 복잡한 트랜잭션이 들어가거나, 복잡한 도메인 지식이 필요한 경우
- 그린 필드 프로젝트
2. DDD Lite :Transaction Script 형태의 구현
- 상태가 없고, 하나의 Operation만을 가진 UseCase 클래스 구현
- 개별 로직이 복잡한 트랜잭션이 있으나, 숫자가 많지 않고 각 UseCase의 연관성이 떨어질 때
3. No Domain : 도메인으로 분류되지 않는 계층의 구현
- 데이터 조작이 단순한 경우
- 데이터 게층에서 얻은 엔티티를 UI의 State로 변환하는 역할이 중요하는 경우
- ViewModel에서 중복되는 재사용 코드들이 Service 형태로 분리시키는 것이 유리한 경우
DDD의 전술 패턴 : 값 객체 (Value Objects)
- ID가 없으며, 객체가 갖고 있는 값 자체로 구별됨
- 불변성을 가진다.
- 다른 인스턴스라도 값이 같으면 같은 객체로 인식한다.
- Kotlin의 inline 클래스를 활용할 수 있다.
Value Objects가 왜 필요한가?
- 각 타입을 개념을 명시 (String → ProductId, Address)
- 불변성 → 상태 변경 체크에 유리함, 함수내의 사이드 이펙트 제거한다.
- 개발자의 실수가 컴파일 시에 드러난다.
DDD의 전술 패턴 : 레포지토리 (Repository) 패턴
- 데이터 컬렉션에 대한 의미
- 도메인 계층에서 필요한 기능만 제공
- 하나의 의미론적인 단위가 구분될 때 레포지토리로 구분
- 레포지토리는 데이터 저장 방식이 설계에 영향을 미치는 것을 막아주는 Low level 수문장
