Page History

...

• A : 인터페이스가 인프라에 바로접근한다란 의미가 아니고, 의존요소를 활용한다란 의존성을 나타낸 그림입니다.  MVC의존 규칙에 벗어나지는 않지만 DDD규칙에 어긋납니다.
• B : 위에서 아래요소를 의존할수 있지만, 아래에서 위 요소를 의존(참조) 할수 없습니다. 도메인 객체는 애플리케이션의 객체 참조를 얻을수 없습니다. ( DI는 프레임워크별로 학습해야하는 영역입니다.  )
• C : 어플리케이션도 도메인 요소중하나이며, 다른 서비스와 협업이 필요할시 n개의 서비스를 가질수 있습니다. 어플리케이션은 여러서비스를 다루는 집합서비스로 이해하면 될것같습니다.
• D : 일반적으로 한단계 아래 의존요소를 활용하는것이 원칙입니다 예를들면 UserController가 Service를 건너 뛰고 인프라요소를 직접 조작하면 안됩니다. 도메인의 중요 규칙은 Service에 존재해야하기
  때문입니다. 하지만 서비스의 트랜잭션 전체를 실패시키는 패턴이 있을경우 계층을 넘어서는 경우가 발생하기도 합니다.
  
  
• E : 해당 서비스와 관련있는 entity는 서비스에 의해서만 조작명령이 수행될수 있습니다.
• F : DataBase를 조작하는 행위는 인프라에 해당하며, 도메인영역과 완전하게 분리합니다. 이것은 레파지토리 패턴에서 잘 설명되어 있습니다. 이것은 ORM이던 아니던 상관없습니다. 

Application LayOut

위 내용을 근거로 API의 어플리케이션 레이아웃을 정의해봅니다.

어플리케이션의 규모에따라 네임스페이스의 계층이 더  체계적이고다양해질수 있으며

도메인 핵심개념을 분리하는것이 주 목적이며 ,선택한 아키텍처에따라 아키텍처의 계층구조및 네이밍이

어플리케이션의 계층및 네임스페이스에 반영될수 있습니다.

Image Removed구현해야할 도메인의 규모와 종류는 다를수 있으면 그에 따른, 적합한 아키텍처를 선택할수 있습니다.

여기서는 선택한 아키텍처와, 어플리케이션의 구현구조를 일치화하는것입니다.

Image Added

이 아티컬에서 구현시도 예정인 Application Layout