Domain Driven Design을 위한 프로젝트 구조

이번 포스팅은 Domain Driven Design에 기초한 프로젝트 구조 입니다. DDD를 적용한 프로젝트 구조를 만들기 위해서 예전에는 Layered Structure를 사용하였으나, 요즘은 Onion Structure를 사용합니다. 양파 구조에 대해서는 이 포스트를 참고하세요. http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

위의 스크린샷은 제가 사용하고 있는 프로젝트 구조입니다.

• Domain : 모든 비즈니스의 핵심이 이곳에 위치합니다. 모든 Entity와 Entity 행동, 그리고 적용된 패턴을 비롯하여 레파지토리 인터페이스가 위치합니다. 이 프로젝트는 절대로 Third party 라이브러리 또는 인프라스트럭쳐 관련된 라이브러리가 존재해서는 안됩니다. 많은 개발자들이 실수하는 것 중에 하나가 이곳에 Third party 라이브러리를 넣는 것입니다. 예를 들어 이메일을 발송하는 모듈이나 결제 관련된 것을 연동하는 것들이 이곳에 넣는 실수를 많이 봅니다. 외부 모듈이 필요할 경우 어뎁터 패턴을 사용하여야 하며, 이곳에는 인터페이스만 정의해 둡니다.
  
  
• Infrastructure : 도메인과 상관 없는 외부 모듈의 구현 또는 인프라스트럭쳐 관련 코드들이 여기에 들어갑니다. DB와 연관된 Repository, SMTP 연동 모듈 등 외부 환경에 의해 변경될 수 있는 Infrastructre 관련 코드들이 구현되어야 합니다. 물론 Domain에서 정의한 Adapter의 구현도 이곳에 두게 됩니다.
  
  
• WebMvc : MVC 패턴 관련된 Presentation Layer입니다. 저는 Dependency Injection 설정도 이곳에 두고 있습니다. 프로젝트 시작점이 이곳이라 어쩔 수 없이 이곳에 두고 있습니다.

위의 구조로 봤을 때 Domain은 Infrastructure와 WebMvc에 의해 참조 되며, Infrastructure는 WebMvc에 의해 참조 됩니다. 물론 이것은 일반적인 양파 구조에 위배되나 Dependency Injection을 위해서는 피할 수 없습니다.

WebMvc와 Domain 사이에 Application 또는 Core라는 프로젝트를 둘 수도 있습니다. 향 후 WebApi 또는 윈도우 어플리케이션 프로젝트가 추가될 경우를 생각해 이 Layer에다가 CQRS 패턴을 위한 Command나 Query 등을 구현해 놓거나 합니다. 이건 취사 선택이 될 수 있겠네요. 저는 Applications라는 폴더를 WebMvc에 넣어두고 사용하다가 위와 같은 요구 사항이 발생하면 따로 프로젝트를 빼내는 방식으로 하고 있습니다.

보기에는 심플한 구조이지만, 저도 완전하게 이해하고 적용는데 시간 좀 걸렸습니다. 한 번 익숙해져서 이렇게 구조를 만들어 놓으면 개발 구조가 매우 깔끔하고 이해하기도 쉽습니다. 이곳 왠만한 개발자는 위 구조에 익숙하기 때문에 저렇게 잡아 놓으면 알아서 프로젝트 구조에 따라 각종 클래스들을 생성하여 잘 개발합니다.

깨끗한 프로젝트 구조로 Happy coding 하세요.