DDD 4 Layers + Clean Architecture 적용해보신 분 계신가요? 효율성이 있는건지

Question

안녕하세요 현재 rest api 서버 개발 중인데기존에는controller(DTO) -> Service(DTO or Domain Entity) -> Repository그냥 흔한 MVC 패턴으로 디자인해서 개발했었으니이번에는 MSA도 추후에 고려할 거기 때문에 범용적으로 많이 쓰이는 DDD로 개발하려 했습니다.우선 제가 해당 아키텍처를 도입하려는 이유는 다음과 같습니다."개발 규모가 커질수록, 중구난방되는 패키지로 인하여 유지보수성 저하를 절실히 느꼈기 때문"입니다.그래서 찾아본 개념이 바로Layered Architecture (4-tier)입니다.해당 아키텍처의 구조는presentation -> application -> domain -> infra형태로 요청을 처리하도록 되어있는데문제는이 DDD의 핵심은 관심사의 완벽한 분리더라구요.그러다보니, 각 계층마다 사용되는 것들을 다른 곳에서 의존하지 않도록.. 별에 별거를 다 만들고 있습니다.아래 제가 공부하고 이해한 흐름을 적어놨는데 우선.. 맞는지 봐주시면 감사할 것 같습니다.presentation에서 controller로 dto로 데이터를 받습니다.이를 application 계층으로 전달 시, command 객체로 mapping해서 전달합니다.application은 usecase나 facade로 정의되어 있으며, domain 계층의 서비스를 활용해서 도메인 단위 기능을 수행합니다.그리고 해당 계층에서 트랜잭션을 관리합니다.application의 usecase는 domain 계층의 서비스를 호출할 때 변환된 command 객체를 domain entity로 변환해서 전달합니다.이때 4번과정에서 domain entity 내부에는 또 vo를 정의해둡니다.해당 vo에는 입력값 검증을 포함한, 비즈니스 로직을 정의하고 있습니다. (주문 총액 계산, 이메일 형식 등..)이렇게domain 계층의 서비스는 domain entity를 사용하여 일반적으로 DB read 작업을 위주로 비즈니스 규칙을 정의합니다. (이메일 중복검사 등)이렇게 application의 usecase는 domain 계층의 서비스를 이용해서 infra에 존재하는 영속성 엔터티를 통해 데이터베이스에 반영합니다.그런데 아무리 생각해도너무 비효율적인 것 같아서요..과도한 매핑 오버헤드 발생각 변환 단계마다 새로운 객체 생성과 데이터 복사가 필요함 (메모리 낭비 및 성능저하 유발 가능성)이라는 문제점이 있는 거 같은데스택오버플로우나 레딧 등 해외 포럼을 뒤적거려봐도명확히 정의된 내용이 없더라구요왜? 정답이라는 게 없다 보니깐요...누구는 영속성 엔터티(흔히 알고 있는 @Entity가 붙은 클래스)에 비즈니스 로직을 담아도 된다 하고누구는 절대 그러면 안된다 하고그리고 누구는 실제로 많은 객체 변환이 일어나지만, 대부분의 현대 애플리케이션에서는 이로 인한 성능 저하는 미미하고, 유지보수성을 되게 높여주니 꼭 DDD 원칙에 맞게 써야 한다는 의견도 있고...ㅎ물론 각 프로젝트 규모에 따라 적용하는 게 맞다고는 생각합니다.다만, 우선 대규모 서비스가 된다는 가정하에 개발하고 싶어서 그렇습니다 ...ㅎㅎ그래서 그런지 어떤식으로 개발해야 할지 도통 감이 안 잡힙니다.물론 정답은 없어서 저만의 개발 규칙을 만들어도 되지만, 이게 "정말 비효율적"이 될 수도 있다는 생각하에널리 표준적으로 채택되는 방법이 있나 궁금하기도 하고,여러 개발자분들의 의견과 생각이 궁금하여 작성하게 됐습니다.

박레고 · Answer

엔티티는 핵심 비지니스 로직을 가질 수 있습니다.정확히 이야기 하면 거의 불편하는 룰이겠지요. (필수 값 검증, 사용자 상태 전환등)각 레이어간에 전달 시 매퍼를 통해서 매핑을 하게 되는데 실제로 상당히 반복적인 작업이 많이 들어가고 불필요하다고 생각이 들 수 있습니다. 성능에 따라 어느선까지 매핑을 할지 팀원간의 조율이 필요한 것 같습니다.과거 저의 경우 프로젝트 할때 레이어간 데이터 전달 시 전체 다 매핑했습니다. 확실히 유지보수 할때는 엄청 편합니다.어디를 고쳐야 하는지 모두가 알거든요.선택은 개발자님의 몫입니다.

chytonpide · Answer

https://okky.kr/questions/1535210#answer-797149제가 얼마전에 단 답변인데 일부 도움이 될수 있을 것 같습니다.전형적인 트레이드 오프가 필요한 상황이군요. 저라면 구현의 편의에 조금더 값을 칠것 같습니다.도메인간은 분리시켜야 하구요. 레이어간에는 의존방향이 중요합니다. 도메인간 분리만 잘 되어도(API를 통해서 의존 - 약하게 결합), 시스템 전체의 복잡도를 관리할 수 있습니다. (유지보수 및 확장이 용이해집니다.)

호두까면주름생김 · Answer

이 고민은 개발을 혼자하기 때문에 발생하는거임.만약 각 레이어에 Dto 컨트롤러부터 그대로 쓰면, 발생할 거라 예상하지 못헀던 에러나 예외가 발생할수도, 발생하지 않을수도 있음. 작업자 2명이 각각 컨트롤러 구현, 서비스 구현했던 과거의 SI 프로젝트들도 대거 있었던 것 같고, 레이어 별 dto 를 사용하는 것은, 레이어 별 zero trust 를 구현하는 것과 비슷한 이치라, '대규모' 라면 '안전한' 방식으로 구현해야 할 같음.그리고 메모리 효율과 관련한 부분이긴한데, 애초에 controller 가 비대한 데이터를 들고 오는 경우가 없고 보통 repository 가 그렇지 않음? Controller 단의 데이터 복사는 하드웨어 성능과 애플리케이션 엔진의 성능을 고려했을 때 문제가 없을 것 같음.

장독깨기 · Answer

정답이 없다는 것을 스스로 잘 알고 계시네요, ㅎ 그렇습니다. 정답 없습니다.자꾸만 정답을 찾으려는 사람이 있고, 정답이라 우기는 사람이 있을 뿐이죠.본인만의 규칙을 효율성을 생각해서 한 번 만들어보세요. : )

안녕하세요플레 · Answer

계층을 분리한다는 건 중복이 발생한다는 것입니다. 그렇다면 계층의 수 만큼 중복이 늘어나겠죠. 잘못된 게 아닙니다. 그래서 클린 아키텍처 같은 것을 도입하면 아키텍처가 단순했을 때보다 코드가 매우 늘어납니다.

DDD 4 Layers + Clean Architecture 적용해보신 분 계신가요? 효율성이 있는건지

5개의 답변

#layered-architectrue 목록