DDD(도메인 주도 개발)

DDD(Domain-Driven Design)라는 소프트웨어 개발 방법론이 있다.

사람들은 왜 이것에 열망하는지? 무슨 장점이 있길래? 이와 반대되는 개념은 뭐가있는지? 이런걸 좀 알아보았다.

---

DDD란 - 도메인 주도 개발

• 1. 대규모 서비스의 복잡한 비즈니스 로직을 체계적이고 명확하게 표현하고 관리하기 위함.

-> 비즈니스 로직을 관리하기 위해 '도메인 모델' 을 중심으로 개발을 한다고 한다.

• 2. 비즈니스 전문가와 개발자가 동일한 언어로 소통하기 위함

-> 코드와 비즈니스 용어가 일치하도록 설계한다.
이때 사용하는 언어가 '유비쿼터스 언어' 라고 한다. (비즈니스 + 개발 공통 언어)

• 3. 도메인을 Bounded Context 로 분리하여 책임을 명확하게 한다.

주문관리 와 재고관리 가 서로의 로직에 영향을 주지 않게 '독립성'을 보장한다.

• 4. 레이어드 아키텍쳐 ( 도메인레이어 + 애플리케이션레이어 + 인프라레이어 ) 로 구성되어서 도메인 로직을 명확하게 구분하여 관리한다.

명확하게 분리가 잘 되어있으면 부분적인 수정이 시스템에 영향을 미치지 않는다. 코드 변경시 리스크 감소

• 5. 단위 테스트 용이성

도메인 로직이 분리되어있기 때문에 테스트하기에 무척 용이하다고 한다.

결국 DDD 란

도메인 (주문, 재고관리, 배송, ...)에서의 규칙을 정해놓은 부분을 도메인이라고 하고
이 도메인을 객체지향적(확장성+유지보수성)으로 개발하는 방법론이다.

---

TS란 - 트랜잭션 스크립트

트랜잭션 스크립트는 DDD와 거의 반대되는 개발 방법론이다. (다른것이지 틀린건 아님)

절차 중심적인 설계를 한다.

DDD와의 차이점

TS는

1. 절차지향적이다.

2. 데이터를 직접 조작하며 비즈니스 로직이 코드에 그대로 들어가있다.

3. 코드의 흐름이 명확하게 짜여져있어서 이해하기가 쉽다.

4. 작은 규모의 프로젝트에 적합하다.

하지만 이러한 점들에는 한계점이 있는데

코드의 중복이 많이 생긴다는 것.

그리고 코드 한 부분을 수정하면 다른 부분까지 수정해야 하는 경우가 자주 생김

---

아직은 개념적인 부분에 대해서 접근하고 있고 조금씩 넓혀나갈 생각이다.