Service 클래스를 역할에 따라 나누는 것이 좋을까?

의견 추가하기↓ / SLiPP 최신의견↓
자바지기 2012-11-17 10:05

최범균씨가 작성한 DDD 구현 기초(http://www.slideshare.net/madvirus/ddd-final)) 문서를 보다가 색다른 부분이 있어 같이 이야기해 봤으면 하는 부분이 있어 가져와 본다.

DDD 구현 기초 문서의 41 페이지를 보면 위와 같이 Service를 역할에 따라 두 가지로 구분해 구현하고 있다. 지금까지는 나는 하나의 Service 클래스에 모든 구현을 하고 있던지라 다소 생소한 부분이 있어 페이스북을 통해 문의를 했더니 다음과 같은 답변을 받았다.

그런데 이와 같이 구현하고 있는 사람이 또 있었다. 각각의 역할에 대한 이름이 다를 뿐이지 윤주선씨가 같은 구조로 구현하고 있는 것을 확인할 수 있다. 이와 같이 구현하는 것에 대해 어떻게 생각하는가? 나도 아직까지 이와 같이 구현하는 것에 대한 경험이 없기 때문에 생각을 정리하지 못했다. 이와 같이 구현하는 것에 대한 장,단점에 대해 논의해 봤으면 좋겠다.

9개의 의견 from SLiPP

자바지기 2012-11-17 14:01

@daydreamer 저도 CQRS와 위에서 최범균님이 제안한 구조에 대해서 정확하게 몰라 제대로 된 답변을 드리기는 힘들겠네요. 구조는 비슷해 보여도 의도가 다른 경우들이 많아서요.

제가 대략적으로 살펴봤을 때는 비슷한 구조라는 생각이 듭니다. 단 CQRS에서는 Command Query용 클래스를 분리하고 같은 Level로 두고 있는데 최범균님의 문서에서는 두 개의 Layer로 표현하고 있네요. 최범균님의 문서에서 Layer가 구분되어 있기는 하지만 의도적인 부분으로 판단했을 때 CQRS와 비슷한 것이 아닌가라는 생각이 듭니다.

자바지기 2012-11-17 14:30

박성철님은 https://www.facebook.com/fupfin/posts/499236183440392 글에서 다음과 같이 남겨 주셨네요.

저는 반대하는 편입니다. 서비스를 만드는 이유와 종류가 다양하기는 하지만, 개념적으로 상위 수준에서 설계가 되어야 한다고 보는데, 저런식으로 구분하다보면 서비스가 상위 개념이 아닌 인프라 구조가 그대로(기계적으로) 드러나는 방식으로 만들어지기 쉽습니다.

저는 이런 상황을 자주 Service는 Use Case와 매핑이 되고 Repository는 DB Table과 매핑이 된다고 자주 표현합니다.

그리고 애플리케이션 서버와 클라이언트가 별도 시스템으로 분리되는SOA 성격의 분산 아키텍처가 아니라, 대부분의 웹 애플리케이션처럼 다중 계층 단일 애플리케이션이라면 도메인의 요소(엔티티, 값 객체, 저장소 등)을 그대로 클라이언트에 노출해도 문제되지 않습니다.

자바지기 2012-11-19 18:56

@beomkyun.choi 의견 감사합니다. 이 내용과 관련해서는 의견이 분분할 것이라 생각합니다. 요구사항 따라 적재적소에 사용하는 경험을 쌓을 필요가 있다는 생각이 드네요.

저도 지금까지 OPIV를 주로 사용해 왔습니다. 범균님의 의견대로 각각의 역할에 맞게 구분해서 구현하는 것이 대해 한번 학습해 보겠습니다. 좋은 생각꺼리를 제공해 주셔서 감사합니다.

beomkyun.choi 2012-11-19 19:06

자바지기 어디까지나 저 개인적 의견과 취향이지 이게 정답이라고 말하는 건 아니니까 오해하면 아니 아니~ 아니 됩니다. 당연히 다양한 의견이 나올수록 좋구요.

그리고, 개인적 의견으로 DDD라는 건 책의 제목처럼 복잡한 도메인에 대한 것이지, 단순한 데이터 구조 중심의 어플리케이션인 경우에는 적용의 의미가 약하다고 봅니다. 도메인 엔티티/밸류 간의 연관이 다소 복잡하고 엔티티와 밸류에 기능이 많을수록 DDD 적용이 효과적이라 생각하고, 구성원이 DB/SQL 중심에 익숙한 경우 객체 중심의 DDD 보다는 데이터 구조 중심의 DAO 방식이 맞는 접근이 아닐까 생각됩니다.

Kenny 2012-11-19 23:33

일단 저는 @beomkyun.choi 님 쪽 디자인을 선호하는 편입니다.

이전에 Interface 우선 설계에 관한 글에서도 나타냈듯이, Interface를 행위 그룹 개념으로 바라보고, Interface는 Pure Design, Class는 mix of a design and implementation (An interface is an expression of pure design, whereas a class is a mix of design and implementation.) 관점에서 바라본다면, 사실 Service Layer 라는 녀석의 위치 자체가 에메해 집니다. Service의 디자인을 의미하는지, mix of design and implementation을 의미하는지, Class 의 모습으로 설계했다면 <>라는 스테레오 타입이 무안하겠죠? 행위 그룹이라는 의미라면, DataLoadingService라는 이름도 그리 어색하지 않고, Converting Service를 제공하는 그룹에 대한 설계로 해석했을 시에 크게 어색하진 않은 듯 합니다.

@beomkyun.choi 님의 의견/취향 부분에서 생각해 본다면, 딱히 이상할 부분도 없다고 보고요. (정답이라는 건 아닙니다. ^^;;; Design 부분에 정답이 있을 리가 없잖아요. 그런게 있었으면 딱 그 모양으로만 만들면 되죠.)

+a 로 개인 견해라면,

ERD에서는 Logical / Physical Design이 너무도 당연시 되면서, 개발 설계/디자인/구현 부분에서는 구현을 위한 디자인 만이 디자인이라고 보여지는 부분은 조금 경계할 필요가 있다고 봅니다. 애초에 Design Pattern 이나, Refactoring이나, PoEAA 쪽에서 설명하는 Class Diagram으로 구현 부분 전부를 설명할 수는 없으니까요. Layer 구분에 대해서도, 제 견해로는 View - Business(Service) - Persistence 로 분리된 형태도 그리 명확해 보이진 않습니다. 저거 사실 어플리케이션의 모습을 정확하게 반영하고 있다고 보기는 어려운 모습이거든요. 걍 이건 브라우저, 이건 서버에서 도는거, 이건 DB로 날릴꺼. 이 정도 구분 밖에는 없지, 이 녀석이 뭘 하는 녀석인지에 대한 이야기는 없으니까요. 오히려, (개인적인 견해지만) 큰 그림 기준으로 봤을 때는, Blue Print 수준에서 크게 문제될 여지가 없다고 봅니다.

beomkyun.choi 2012-11-20 08:58

앗, 저 장표에 잘못된 게 하나 있네요. 이게 거의 최종버전이어서 수정이 안 된 부분이 있는데요, DomainApplicationService는 구현을 제공하는 클래스입니다. 인터페이스가 아닙니다.

의견 추가하기

연관태그

← 목록으로