DDD vs SQL 설계

SQL 주도 설계

정의

DB와 SQL 쿼리를 중심으로 소프트웨어를 설계하는 방식

비즈니스 로직 문제

• DB를 중심으로 설계하기 때문에 Infra에 변경사항이 생길 경우 비즈니스 로직이 수정될 수 있다.
• 실제로는 비즈니스 로직이 더 중요도가 높기 때문에 바람직하지 않다.

객체지향과의 패러다임 불일치

• 객체지향 설계는 객체를 중심으로하여 객체의 기능과 관계를 통해 소프트웨어를 구성하지만 SQL 주도 설계는 DB를 중심으로 데이터를 어떻게 읽고 쓰는지를 중심으로 소프트웨어를 구성한다.
• 서로 다른 특징을 가진 객체를 RDB에 넣을 경우 문제 발생
  • 상속(객체)
  • 연관관계(RDB)
  • 데이터 타입(서로 다른 타입)
  • 데이터 식별 방법(식별 방식이 다르다)
• RDB가 인식하는 언어는 SQL 뿐이다 -> 객체가 중심이 아닌 SQL 중심이 된다

ORM(Object Relational Mapping)

• 패러다임 불일치를 해결하고 객체 중심의 개발을 위해 등장
• 자바는 JPA가 존재

도메인 주도 설계 (Domain Driven Design)

정의

소프트웨어 모델링 시 해당 도메인을 중심으로 개발하는 방식

도메인

도메인의 사전적 정의는 범위, 영역이라는 의미가 있으며 개발에서는 소프트웨어로 해결하려는 영역을 의미한다.

특징

• 도메인 객체가 비즈니스 로직을 가지고 있어 역할을 가지게 된다.
• 서비스의 로직들이 도메인으로 분산되어 서비스가 단순해진다.
• 서비스가 적절한 역할을 가진 여러 클래스로 분산되어 유지보수가 편해진다.

아키텍처

DDD의 Layered 아키텍처는 4계층을 사용한다.
1. presentation layer

• 사용자의 요청을 처리하는 계층이다.

2. application layer
   • 비즈니스 로직을 가진 Service 계층이다.
   • 데이터의 변경 등의 책임은 Domain 계층에 넘기는 것이 중요하다.
3. domain layer
   • DDD의 핵심 계층이다.
   • 실제 도메인의 정보를 가지고 있는 계층이다.
   • entity를 통해 로직을 사용한다.
4. infrastructure layer
   • 상위 계층을 지원하는 기술적 기능 제공(DB)