• Orury의 모듈은 아래와 같이 총 5개로 구성돼 있습니다.

  

• 모듈 안에서 패키지 구조를 DDD 레이어와 일치시켜서 리팩토링을 진행하여, 아래와 같이 DDD Layer에 따른 코드들이 구현돼 있습니다.

  

• 그리고 각 Layer에 해당되는 클래스들은 아래와 같이 작성돼 있습니다.

  

• 이제 일반유저(Client) 모듈에 대해서는 리팩토링을 마쳤다고 생각하고, 아래 그림과 같이 Admin 모듈을 추가하려던 참이었습니다.

  

• 이제 이 Admin모듈을 추가하는 과정에서 문제상황이 발생하고 그 해결책에서 의견 차이가 있어, 여쭙습니다.

  • 문제상황:
    • Admin모듈을 추가함에 따라 Interfaces와 Facade는 당연히 Client와는 독립적으로 개발돼야 함.
    • 그러나, Domain 모듈에 속하는 Service의 경우에도 Admin을 위한 Service를 따로 개발해야 하는가?
  1. Admin모듈을 위한 Service를 따로 작성 X
     • 악성유저가 쓴 글을 삭제하거나 악성유저를 탈퇴시킬 때, Admin을 위한 새로운 Service에서 코드를 구현한다면, 이는 기존 코드와 중복되는 것이 아닐까?
       • Domain모듈에서 Service코드를 일관적으로 관리한다면, 공통으로 사용하는 Service 코드의 중복을 없애주고 높은 일관성을 유지할 것으로 예상.
     • 비록 지금의 Service코드에 일반유저 검증 로직이 포함돼 있다고는 하나, (ex. 게시글 작성유저 id == api 요청으로 들어온 유저 id)
       • ValidationService를 따로 두고, Admin모듈의 Facade와 Client(일반유저)모듈의 Facade에서 각각 알맞은 validationService.validate()를 수행하고 난 뒤, postService.deletePost()와 같이 구현해주면 되지 않을까?
  2. Admin모듈을 위한 Service를 따로 작성 O
     • 1번과 같이 구현한다면, Core모듈이 너무 비대해질 것으로 예상. Service 코드에 Admin과 Client를 위한 메서드들이 전부 다 응집되어, 코드 길이가 늘어나고 가독성이 떨어질 것으로 예상.
     • 가장 잦은 변화가 일어나는 Service가 모듈별로 존재하기에, 각 모듈이 독립적으로 개발되어 개발 프로세스의 병렬화 가능.

질문 1:

위의 1번과 2번 선택지 중, 어느 것이 더 합당한 선택일까요?

질문 2:

2번을 선택한다면, Service는 Domain Layer가 아닌 Application Layer로 보는 것이 합당할 것 같습니다. 아래와 같이, DDD Layer과 클래스들을 매핑하여 생각해도 괜찮을까요? ( = Service를 DDD Layer 에서 Application Layer로 생각하고 구현하면 될까요?)

질문 2-1:

Service의 경우, Application Layer / Domain Layer 모두에 해당될 수 있는 것으로 생각하면 될까요?

예를 들어, “상품 주문, 상품 조회”와 같은 Service ⇒ Application Layer. ”할인율에 따른 상품 가격계산”과 같은 Service ⇒ Domain Layer.