Page History
...
참고링크 : https://wikibook.co.kr/article/layered-architecture/
특이사항 : 계층을 잘 나눠 도메인을 분리하자~
클린 아키텍처
참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html
특이사항 : 같은 이야기이지만, SOA에서 활용이 주로 된듯
헥사고널 아키텍처
클린 아키텍처
특이사항 : 도메인 이벤트를 활용하는 CQRS 영역까지 포함한 아키텍처입니다. 위에서 설명한 아키텍처를 계승하고 양념이 뿌려진듯
결국 아키텍처에서 공통으로 이야기하는 것은 관심사의 분리이며 각 아키텍처마다
동일하지만 분리하는 방식에 사용되는 용어가 약간 다르거나, 의존성을 구성하는 방법 접근방향등에
약간식의 차이가 있는것으로 보입니다. 참고링크 : https://woowabros.github.io/tools/2019/10/02/clean-architecture-experience.html
| Note |
|---|
DDD에서는 아키텍처에서 표현된 도메인 모델과 코드의 일치성을 중요하게 생각하며 더나아가 코드로 도메인 모델이 설명이 되어야한다고 이야기 합니다. 이것은 도메인 코드를 작성하는 개발자가 곧 설계자여야하며 설계자와 코더로 이분화 되었을때, 코드는 결코 설계를 반영하지 않을것이다란 경고를 합니다. |
...
- A : 인터페이스가 인프라에 바로접근한다란 의미가 아니고, 의존요소를 활용한다란 의존성을 나타낸 그림입니다. MVC의존 규칙에 벗어나지는 않지만 DDD규칙에 어긋납니다.
- B : 위에서 아래요소를 의존할수 있지만, 아래에서 위 요소를 의존(참조) 할수 없습니다. 도메인 객체는 애플리케이션의 객체 참조를 얻을수 없습니다. ( DI는 프레임워크별로 학습해야하는 영역입니다. )
- C : 어플리케이션도 도메인 요소중하나이며, 다른 서비스와 협업이 필요할시 n개의 서비스를 가질수 있습니다. 어플리케이션은 여러서비스를 다루는 집합서비스로 이해하면 될것같습니다.
- D : 일반적으로 한단계 아래 의존요소를 활용하는것이 원칙입니다 예를들면 UserController가 Service를 건너 뛰고 인프라요소를 직접 조작하면 안됩니다. 도메인의 중요 규칙은 Service에 존재해야하기
때문입니다. 하지만 서비스의 트랜잭션 전체를 실패시키는 패턴이 있을경우 계층을 넘어서는 경우가 발생하기도 합니다. - E : 해당 서비스와 관련있는 entity는 서비스에 의해서만 조작명령이 수행될수 있습니다.
- F : DataBase를 조작하는 행위는 인프라에 해당하며, 도메인영역과 완전하게 분리합니다. 이것은 레파지토리 패턴에서 잘 설명되어 있습니다. 이것은 ORM이던 아니던 상관없습니다.
Application LayOut
위 내용을 근거로 API의 어플리케이션 레이아웃을 정의해봅니다.
어플리케이션의 규모에따라 네임스페이스의 계층이 더 체계적이고다양해질수 있으며
계층형 아키텍처 베이스로 Application 네임스페이스를 우선은 심플하게 구성하였으며
도메인 핵심개념을 분리하는것이 주 목적이며 , 아직 DDD의 컨셉이 완전하게 반영된 구조가 아니며
재 조정될수 있습니다.
| Code Block | ||
|---|---|---|
| ||
Controllers : API인터페이스 정의
- UserController
Services : 어플리케이션/도메인 계층
-User : User도메인을 응집화
-UserAppService
-UserService
Entity : 엔티티를 집합
-UserEntity
Repositories : 인프라계층중 레파지토리들
-UserRepository |
다음아티컬에서는 위 기본 아키텍처를 베이스로 다음항목을 준비예정입니다.
...
구현해야할 도메인의 규모와 종류는 다를수 있으면 그에 따른, 적합한 아키텍처를 선택할수 있습니다.
여기서는 선택한 아키텍처와, 어플리케이션의 구현구조를 일치화하는것입니다.
이 아티컬에서 구현시도 예정인 Application Layout
...