주니어들 추상화 리팩토링 스터디하면

[김대기(211.219)]

시니어들은 두려움에 벌벌떱니다..

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[김대기(211.219)]

크아앙앗아앗

[김대기(211.219)]

근데 ddd는 실행규칙들에 유용한게 꽤 있어서 추상화랑 조금은 결이 다르긴 합니다

[익명(118.235)]

어쩔 수 없지 객체지향과 아키텍처 스터디 함

[김대기(211.219)]

응기이잇

[익명(118.235)]

아 그럼 대체 뭐하라고

[김대기(211.219)]

농담이에요 ㅋㅋ

[개발뉴비(coderhs)]

실제상황 : 레이어드 아키텍처에서 2번 레이어와 4번 레이어가 통하면 왜 안 되나요?

[김대기(211.219)]

레이어드 아키텍처에서는 4번 레이어의 변경이 2번 레이어에게 영향을 끼칠거라고 예상하지 않기 때문입니다

[김대기(211.219)]

다만, 모든 경우에 그런 것은 아닙니다 예를 들어 controller-service-repository 구조인데, 트랜잭션도 필요 없고 모든 종류의 비즈니스 로직이 다 필요가 없는데, 굳이 무의미한 service 계층을 만들어서 요청을 전달만 하는건 낭비입니다 이건 전체적인 구조가 어떠느냐에 따라 다릅니다 대부분의 클래스가 controller-service-repository 구조로 잘 동작하고 있다면, 일부 클래스가 무의미하더라도 동일한 패턴으로 적용하는게 관리 측면에서 용이합니다

[김대기(211.219)]

레이어가 무의미한 케이스의 양이 많아지면 그때는 다시 고민을 해봐야합니다 애초에 이런 경우가 잘 없기는 한데.. 양이 너무 많고 한 패키지에 집중돼있다면 레이어를 스킵하는 것도 충분히 고려할만 합니다 다만, 해당 케이스가 여러 패키지에 분산돼있고 그 패키지에서는 소수 케이스에 불과하다면 가급적이면 레이어를 거치는게 좋습니다 팀 개발을 할때 가장 중요한 것중 하나가 일관성이라서요

[김대기(211.219)]

개인적으로는 크게 힘든거 아니면 가급적이면 레이어 건너뛰지 않도록 하는게 좋다고 생각합니다 일관성 때문입니다

[개발뉴비(coderhs)]

결국은 표준을 지켜라가 답인듯 ㅎㅎ 누군가 답변이 웃겼는데... 레이어드 아키텍처(였던 것) 이라고 답해줬음

[김대기(211.219)]

저도 표준을 지켜라가 답이라고 생각합니다 레이어드 아키텍처 정도면 지키는데 비용이 얼마 안들거든요 그런데 이렇게 단순하게 말하면 표준 광신도라고 거부감을 가지는 사람들이 있어서..

[김대기(211.219)]

아 그리고 JPA 쓰다보니 서비스 레이어 위로 엔티티 객체를 보내면 안돼서 레이어 건너뛰기를 금지하기도 했었네요 물론 repository에서 VO로 돌려줄수도 있긴 한데, 그건 소수 케이스라서 감안하지 않았고요

[김대기(211.219)]

이것도 어떻게 보면 레이어 간 예상 영향도와 연관이 있겠습니다. 영속성 컨텍스트가 서비스 레이어까지만 유지되니까요