Step5. SQL 중심설계 vs DDD

1. SQL 중심 설계

---

SQL 중심 설계란 전통적인 데이터베이스와 데이터의 흐름을 중심으로 설계하는 방식이다.
데이터베이스의 테이블 구조와 SQL 쿼리를 중심으로 설계하는
아마도 우리에게 가장 익숙한 설계방식일 것이다.

SQL 중심 설계의 특징

• 데이터베이스의 특징과 같이 데이터베이스를 쉽게 구조화할 수 있다.

• 정규화를 통해 데이터베이스의 중복을 최소화하고 일관성을 유지할 있다.

• 데이터베이스의 구조를 중심으로 개발을 진행하기 때문에 데이터베이스의 스키마가 바뀌게된다면 개발 영역 전반적으로 큰 영향을 미치게 된다.

• 또한 데이터베이스 테이블에는 '상속'이라는 개념이 없기 때문에 개발자에게 SQL 매핑작업이 계속해서 요구되고 이 점은 개발 복잡성과 난이도를 올리는 원인이 된다.

2. DDD(도메인 주도 설계)

---

DDD란 도메인(해결하려는 관심 영역)을 중심으로 설계 하는 방식이다.

주요 원칙 및 개념

1. 도메인(Domain)
   시스템이 해결하고자 하는 영역 혹은 비즈니스 영역을 의미한다.
   현실 세계에서 발생하는 연관된 이벤트들의 집합이라고 이야기 할 수 있다.

2. 서브 도메인(SubDomain)
   도메인을 구성하는 도메인의 부분 집합이다.
   (ex. '컴퓨터'라는 도메인이 있다면 'cpu'라는 서브 도메인이 존재한다고 생각하면 된다.)

3. 도메인 모델(Domain Model)
   특정 도메인을 개념적으로 표현한 것이다. 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 된다.

4. 바운더리 컨텍스트(Boundary Context)
   바운디드 컨텍스트는 도메인 주도 설계에서 도메인을 분리하고 각각의 컨텍스트를 독립적으로 개발 및 변경할 수 있는 단위로 사용된다.
   각 바운더리 컨텍스트는 특정 비즈니스 도메인 모델을 포함하고, 모델과 용어를 해당 영역에서 독립적으로 유효하게 된다.
   이렇게 함으로써 도메인 모델이 특정 컨텍스트에서 완전한 의미를 가지게 된다.

5. 어그리게이트(Aggregate)
   각 도메인 영역들의 대표하는 도메인 객체들의 집합
   개별 객체 수준의 모델만을 참고하여 도메인을 분석하게 되면 무엇이 중요하고 핵심인지 한눈에 파악하기가 힘들다.
   하지만 애그리거트 단위로 도메인을 먼저 이해한 후 객체 수준의 모델을 바라보게 된다면 이해하기가 훨씬 쉽다.

6. 유비쿼터스 언어(Ubiquitous language)
   특정 도메인에서 특정용어가 해당 도메인의 의도를 명확하게 반영하고, 핵심 개념을 잘 전달 할수 있는 언어이다.
   간단하게 개발자, 도메인 전문가, 이해관계자 모두가 동일한 의미로 사용되어야 하며 혼동이 없어야 한다.
   같은 말을 했을때, 모두가 같은 의미로 받아들여야 한다

DDD의 아키텍처

레이어드 아키텍처

1. UI : 어플리케이션이 연결되는 계층, I/O통신 변환등을 담당
2. Application : 도메인 객체를 직접 사용하며 어떻게 사용할지를 정의하는 유스케이스를 실제로 구현
3. Domain : 비즈니스 룰 등 도메인과 관련된 직접적인 기능과 그 객체를 이루는 계층
4. Infrastructure : Repository나 Persistence, 메시지 전송과 같은 기술적 기능을 제공

클린 아키텍처

1. External Interface : 데이터베이스나 웹 프론트엔트 프레임워크 기반 UI
2. Interface Adapter : 데이터베이스나 파일시스템과 같은은 외부 시스템에 저장하거나 내부의 유스케이스를 위해 양방향으로 데이터 변환을 담당
3. UseCase : 핵심 비즈니스 로직이나 어플리케이션 로직으로 구성된 계층
4. Entity : 엔티티 또는 도메인으로 구성된 내부의 유효성 검사 혹은 모든 도메인에 적용되는 일반 논리를 가진 계층

핵사고날 아키텍처

클린 아키텍처와 비슷한 개념이지만 port라는 개념을 명시하고 있다.
사용하고자 하는 유틸리티를 각 port에 맞게 구현만 하면 어떤 유틸리티를 가져다 쓸 수 있다.

3. DDD와 SQL 중심설계의 차이점

---

• DDD는 비즈니스 도메인을 중심으로 하며, 도메인 모델링과 비즈니스 로직에 초점을 둔다.
  반면에 SQL 중심 설계는 데이터베이스를 중심으로 하며, 데이터베이스 스키마와 쿼리를 중심으로 하고 데이터 구조를 중심으로 설계한다.

• DDD는 개발자와 비즈니스 전문가 간의 협력을 강조하고, 도메인 모델의 이해와 정의에 중점을 둔다.
  SQL 중심 설계는 주로 데이터베이스 관리와 데이터 구조를 중심으로 하기 때문에, 비즈니스 전문가와의 협력보다는 데이터베이스 관리 및 쿼리 성능에 집중한다.

4. DDD를 사용하는 이유

---

DDD를 사용하는 이유로는 크게 두가지가 있다고 생각한다.

1. 유연성과 확장성: DDD는 바운디드 컨텍스트를 사용하여 도메인을 분리하고, 각 컨텍스트를 독립적으로 개발하고 변경할 수 있도록 한다. 이는 시스템의 유연성과 확장성을 높여준다. 즉, 객체 지향적 설계에 유리하다.(= 결합도(의존도)가 낮아지고 높은 응집도를 추구하는 모듈화와 비슷하다고 볼 수있다.)

2. 비즈니스 중심적 접근 : DDD를 사용하는 또 다른 이유는 기획자(도메인 전문가)와 개발자 및 이해관계자의 도메인에 대한 이해도의 차이를 극복하고 요구사항에 최적화된 개발이 용이하다.

5. 마무리

---

TDD는 알고 있었는데 DDD는 생소한 개념이었다.
정말 간단하게 이야기 하면 실질적(현실적?)인 기능을 하나씩 모듈화 시키고 이것들을 연결시키는 방식으로 설계를 하는데 MSA와 상당히 비슷하다는 생각이 들었다.
DDD와 MSA의 차이점에 대해서도 공부를 해 봐야겠다.