Dto 에 로직이 들어가지 않는다 ?

Q 는 저의 질문이며 , A 의 경우 지인의 답변입니다.

 

A : 주인장 블로그  :  https://headf1rst.github.io/TIL

산하개발실록

 

 

 

Q . 

dto 에 로직이 들어가지 않는다 라는 테크톡의 영상들을 보다가 의문이 생겼습니당,, dto 에 로직을 넣는것이 하면 안되는 행동인가요,,?

 

 

A.

객체지향적으로 봤을때 dto는 말그대로 data transfer object, 데이터를 전달하는 객체이기 때문에, 오직 데이터를 전달하는 책임만을 갖게하기 위해서 로직관련해서는 넣지않는게 객체지향적인 설계일거 같고 그리고 dto는 화면에 필요한 상태값만을 포함하기 때문에

로직 구현에도 그다지 적합하지 않고, 대신 요구사항을 처리할 수 있는 모든 정보를 알고있는 도메인이 요구사항에 대한 로직을 수행하는게 더 편리하고 유지보수에도 용이할거 같어 

 

 

 

(거의 3주 가량의 고민이 들어간 걸 드디어 완성한 기분이 들었네요  :  https://chosunghyun18.tistory.com/79   )

DTO VS VO

 

Q.

서비스 레이어를 얇게 하고 , 엔티티에 비즈니스 로직을 주는 도메인 주도 설계를 하고 싶은데 
선생님이 개발이나 실제 플젝 할때 서비스에 로직 넣고 테스트코드 넣고 엔티티로 로직 넣는 걸 하는지 아니면 처음부터 엔티티에 로직을 넣는걸로 시작하는지 궁금합니당

 

A.

사실 나도 서비스 레이어를 얇게 만들지 못하고 대부분의 개발자가 어려워 할 거 같긴한데, tdd를 도입하는게 난 서비스레이어를 얇게 만드는데 가장 좋은 연습인거 같어 테스트 코드를 먼저 만들게 되면 오브젝트 읽다보면 객체의 상태가 아닌 행위(메서드)를 먼저 정의하라는 내용이 나오는데. TDD는 테스트 코드를 먼저 만들게 되고 테스트 코드는 객체의 메서드를 결국엔 테스트하는 용도기 때문에 자연스럽게 메서드를 먼저 구현하게 되고. , 그 메서드에 필요한 상태들을 추가적으로 고려하게 되서 도메인이 좀더 비대해 질 수 있을거같어. 

TDD랑 테스트 코드도 학습 비용이 있다보니까. TDD를 도입하기 어렵다면 유스케이스를 잘 정의하려고 노력했던거 같어

 

Q . 답변 감사합니당,, ㅠ ㅠ
추가 질문은 인터페이스를 객체간 메시지를 전달하기 위해 거의 필수 급으로 중요하다라고 하는데 바로 구현체를 만들지 않고 인터페이스를 만들면 많은 장점이 있기는 한데 오버 프로그래밍이라고 봐도 될까요?  아직 인터페이스가 낯설어요 ,, 

 

A. 백기선님도 말했는데, 아마 큰 규모의 프로젝트를 하는게 아니면 프로젝트 내에서 인터페이스의 중요성을 느끼기 힘든것 같어,아마 스프링의 내부랑 DI 공부하면서 인터페이스의 중요성이 이해되긴 하는데 플젝에서는 DI 대상이 되는 객체인 경우에는 인터페이스를 만들어서 구현하라고 하기는해  , service랑 repository 객체에 인터페이스 만들라고는 하는데, 토비님이랑 백기선님은 DI 대상 되는 객체엔 무조건 인터페이스 만들어서 구현하라고 하고 김영한 님 같은 경우에는 service는 굳이 인터페이스 안만들어도 된다함.

 

Q. 

네넹 , 마지막으로 엔티티가 커지면 서비스레이어가 얇아지는데 , 그럼 구조적으로 서비스 레이어가 굳이 필요한 ? 쓸모 없는 요청을 하는 경우가 생겼습니당,, 이런걸 싱크홀 안티 패턴이라고 하는데 , 또 토스 슬래쉬 강연을 보면 레이어를 건너뛰지 않는다라는 팀 내부적인 조약이 있습니다.
이런것 처럼 서비스 레이어에서 생길 수 있는 불필요한 오버헤드는 성능과 레이어의 통일성 사이의 트레이드 오프라생각 해도 되는지?

 

 

A.

단순 도메인의 필드값 하나를 변경하는 로직일 경우에는 컨트롤러에서 바로 레포로 갈 수도 있지만 그렇게 되면 컨트롤러가 있는 웹 계층에 도메인 로직이 구현되게 되면서 ,,,

 

Q. . 아 그럼 유지 보수가 ??

 

A.  얍얍 , 유스케이스 확장되면 도메인 로직이 웹 계층까지 섞이게 되고 책임이 모호해지게 되고, 테스트 시에도  컨트롤러가 있는 웹 계층을 테스트 할 경우에 레포가 있는 영속성 계층도 함께 mocking해야해서  테스트 복잡도가 증가한다는 문제가 있는데

이게 많이들 쓰는 계층형 아키텍처의 문제라고 하더라고,, 컨트롤러에서 레포로 바로 갈 수 없게 제한하는게 없기 때문에

사진 처럼 제약이 없다는게 계층형의 문제라서,, 요즘은 헥사고날 아키텍처 기업들이 많이써

 

 

추가 이와 같은 고민은 다들 합니당

 

Service레이어를 인터페이스로 추상화 하는 이유는 무엇인가요?

 

https://www.inflearn.com/questions/69278/service%EB%A0%88%EC%9D%B4%EC%96%B4%EB%A5%BC-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4%EB%A1%9C-%EC%B6%94%EC%83%81%ED%99%94-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94     

Service레이어를 인터페이스로 추상화 하는 이유는 무엇인가요? - 인프런 | 질문 & 답변

영한님 답변 :

 

* 이상적으로는 모든 설계에 인터페이스를 부여하자

실무 고민

* 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다.

* 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다.

 

 

어 추상화 비용이 뭐지 ??

 

https://www.inflearn.com/questions/779605/%EC%B6%94%EC%83%81%ED%99%94%EB%B9%84%EC%9A%A9%EC%9D%B4-%EB%B0%9C%EC%83%9D%ED%95%9C%EB%8B%A4%EB%8A%94-%EA%B2%83%EC%9D%B4-%EA%B6%81%EA%B8%88%ED%95%A9%EB%8B%88%EB%8B%A4-%EC%98%81%ED%99%98%EB%8B%98

추상화비용이 발생한다는 것이 궁금합니다 영환님! - 인프런 | 질문 & 답변

영한님 답변 :

 

추상화 비용이 발생한다는 것은 여러가지 의미가 있습니다. 그 중에 가장 어려운 것은 코드가 복잡해진다는 것입니다. 추상화가 없다면 그냥 코드를 따라가면 되는데, 추상화가 있으면 추상 인터페이스를 보고 어떤 구현체가 실제 동작할지 또 추가로 찾아야 하는 과정을 거쳐야 합니다. 쉽게 이야기해서 코드를 계속 따라가기가 어렵습니다.

 

이 부분은 성능에 대한 부분이라기 보다는 복잡도에 대한 부분입니다.

 

추상화를 하면 구현체를 갈아끼울 수 있어서 확장성이 늘어나기 때문에 유지보수하기 더 좋아지는 부분도 있지만, 반대로 추상화가 꼭 필요하지 않은 곳 까지 추상화하게 되면 코드를 유지보수하기 더 어려워 질 수 있습니다.

경험 많은 좋은 개발자라면 이런 부분을 적절히 잘 선택할 수 있어야 합니다

 

 

 

 

문답의 소감 :

네트워킹이 중요하다라는 점을 느꼈습니다.  설계란 코드의 배치를 뜻한다 라고 표현이 있는만큼 코드 한줄 한줄 작성하는것의 고민들이 

어느정도 풀렸습니다. 앞으로 이블로그에 위의 답변을 참고하여 이전 프로젝트를 리펙토링 하는것을 올릴 계획입니다.

 

 

 

다시한번 지인이자 선생님인 산하님께 감사를,,