[Architecture] DDD 설계와 SQL 중심 설계

본문 요약

분류	DDD 설계	SQL 중심 설계
개념	도메인을 중심으로 설계해 나아가는 방법	데이터 중심으로 설계해 나아가는 방법
특징	1. 도메인의 개념을 먼저 정의하고 구현한다. 2. 각각의 도메인이 철저히 분리돼 변경과 확장에 용이하다. 3. 도메인의 복잡성 해결에 힘쓴다. 4. 개발자와 도메인 전문가의 협업을 통해 커뮤니케이션 문제를 해결한다.	1. 관계형 데이터베이스의 테이블을 먼저 만들고 엔티티를 설계한다. 2. 도메인 변경 시 RDB의 테이블과 쿼리도 모두 수정해야 한다. 3. 데이터베이스의 효율성과 최적화를 중요시한다. 4. 협업을 고려하지 않은 개발자 위주의 용어 선택으로 커뮤니케이션 문제를 야기할 수 있다.
차이점	1. 도메인 중심의 설계 2. 객체지향적 3. 도메인과 데이터의 느슨한 결합	1. 데이터 중심의 설계 2. 객체지향적이지 않음 3. 도메인과 데이터의 강한 결합

도메인 주도 설계(Domain Driven Design, DDD)
- 도메인을 중심으로 설계해 나아가는 것
- 데이터 중심 설계에서 벗어나는 것
DDD의 주요 요소 3가지
- 유비쿼터스 언어(Ubiquitous Language)
  - 개발자도 알고 도메인 전문가(기획자)도 아는 보편적인 언어
  - 비즈니스 용어를 하나로 통일한 공통의 언어
  - 커뮤니케이션 문제를 없앨 수 있다.
- 전략적 설계(Strategic Design)
  - 개념적 설계
  - 도메인 이해 관계자끼리 유비쿼터스 언어로 도메인 지식을 공유하고 이해한다.
  - 개념과 경계를 식별해 바운디드 컨텍스트(Bounded Context)로 정의한다.
    - Bounded Context에 따라 Model의 역할과 책임이 달라진다.
    - 문맥에 따라 객체의 역할이 바뀐다.
  - 경계의 관계를 컨텍스트 맵(Context Map)으로 정의한다.
- 전술적 설계(Tactical Design)
  - 구체적 설계
  - 전략적 설계에서 도출된 바운디드 컨텍스트와 도메인을 이용하여 애그리거트 패턴, 엔티티와 값 객체, 레포지토리 등을 구성하고 구현한다.
DDD의 핵심 목표
- Loose Coupling(느슨한 결합)
- High Cohesion(높은 응집도)

데이터 중심 설계
- 데이터를 중심으로 설계해 나아가는 것
- 관계형 데이터베이스 테이블의 구조를 먼저 설계하고, 데이터베이스의 CRUD 작업을 중심으로 시스템을 개발한다.
- 데이터의 저장과 검색을 효율적으로 처리하기 위해 DB를 최적화하는데 초점을 맞춘다.
관계형 데이터베이스는 비즈니스 도메인에 수정할 것이 생기면 데이터베이스 테이블과 쿼리도 다시 수정해야 한다.
- 휴먼 에러가 발생할 가능성이 높아진다.
- 비즈니스 도메인과 데이터베이스의 구조가 강하게 결합된 것을 알 수 있다.
관계형 데이터베이스에 객체지향을 완벽하게 녹일 수가 없다.
- 관계형 DB는 데이터를 정규화해서 저장하는 걸 목표, 객체는 캡슐화해서 쓰는 걸 목표로 만들어졌기 때문이다.
- 열심히 객체지향스럽게 만든 객체 ➡️ SQL로 변환 ➡️ 객체지향스럽지 않게 RDB에 저장
  - 객체를 테이블에 맞춰 모델링하기 때문에 객체지향스럽지 않게 된다. 객체지향스럽게 모델링하면.. 매핑작업이 늘어나 일이 번잡해진다. (SQL 매퍼가 된 개발자 🧟 : 사...살려줘!!)