1부에선 Clean Architecture의 창시자, Uncle bob의 블로그를 최대한 번역하여 설명하는 내용으로 포스팅 하였다.
이번 포스팅에서는 Clean Architecture와 DDD 그리고 Domain에 대해서 알아보자.
DDD, TDD 그걸 왜 알아야해?
우선 Clean architecture를 보다가 갑자기 DDD와 Domain 알아보자고 해서 놀라신 분들을 위해 먼저 "왜" 알아야하는지 설명부터 하는게 맞을거같아 설명을 해드리겠다.
Domain과 DDD이란 ,
Domain : 비즈니스 도메인이라고도 불리며, 소프트웨어가 해결하거나 다루려는 현실 세계의 문제 영역을 나타낸다.
예를들어, 은행 애플리케이션에서 도메인은 고객, 계좌, 거래와 같은 금융 분야의 주제를 포함할 수 있다.
DDD(Domain Driven Design 도메인 주도 설계) : 소프트웨어 시스템의 설계 및 구현에 있어 도메인을 중심으로 개발하는 방법론이다.
이다. 그래서 이게 왜 관련이 있는데? 라고 한다면, 앞서 포스팅한 그림을 다시 가져와서 설명해보도록 하겠다.
Clean Architecture에서 Uncle bob의 이미지는 많이 봤을 것이다. 우측은 의존성 규칙을 고려하여 클린아키텍쳐를 layer별로 나눈것을 표현한 것이다. 결국 레이어별로 어떻게 의존성을 가져야하는지 시각화한 것이라고 할 수 있다.
그래서 여기서 Layer가 3개로 나누어지고 각 계층에 대한 설명은 다음과 같다.
- Domain Layer (도메인 계층)
- 가장 안쪽에 위치하며 다른계층의 의존하지 않는다. Entity Use Case 그리고 Repository Interfaces를 포함하며 Usecase는 1개 이상의 Repository Interface에서 데이터를 결합한다.
- Domain layer는 다른계층에 의존하지 않아야하며, 비즈니스 영역의 핵심 로직을 담당한다.
- Presentation Layer
- UI를 포함하며, Presenter는 1개 이상의 Use case를 실행한다.
- Domain Layer에 의존한다. 비즈니스 로직과 규칙은 Domain Layer에 관리되고, Presentation Layer는 UI에 표현한다.
- Data Layer
- Repository Implementations와 1개 이상의 Data source를 포함하며, Repository Data sources로 부터 데이터를 조정한다.
- Domain Layer에 의존하며, 데이터 접근 및 조작을 담당하는 계층으로 비즈니스 로직은 Domain Layer에서 처리된다.
각 계층에 대한 설명은 다음과 같다. 물론 이해가 잘 되지 않으면 넘어가도록하자. 다음 포스팅에서 코드로 예시를 들며 다시 설명하도록 하겠다.
그래서 결론이 뭐야?
결국 DDD도 Domian Driven Design이므로 Domain이 중요하다. 즉 비즈니스 로직이 핵심이라는 뜻인데, 클린아키텍처에서도 동일하게 비즈니스 로직이 핵심이라는 뜻이다.
결론은 "도메인을 우선으로 설계를 해야하고 그 도메인을 바탕으로 개발을 진행해야 한다." 가 주된 내용이라고 하고 싶었다.
도메인의 정의. 잘 정해서 클린아키텍처를 시작해보도록 하자.
다음 포스팅은 각 레이어에 대한 내용을 조금 더 깊게 설명하도록 하겠다.
'Study > 기타' 카테고리의 다른 글
| Clean Architecture 클린아키텍처, 객체와객체지향 프로그래밍[4부] (0) | 2024.03.20 |
|---|---|
| Clean Architecture 클린아키텍처, Flutter 폴더구조에 대하여[3부] (0) | 2024.02.25 |
| Clean Architecture 클린아키텍처에 대하여 [1부] (0) | 2024.01.08 |
| 3. REST API에 대한 이해 (0) | 2022.02.20 |
| 2. Reactive Programming (0) | 2022.01.18 |