cascade 질문입니다.

답변 정말 감사합니다.

앞으로의 개발인생에 큰 도움이 될 것 같습니다.

남은 강의도 즐겁게 시청할게요 :)

안녕하세요. pwnable님 좋은 질문입니다.

이 부분은 사실 정답이 있다기 보다는 수 많은 트레이드 오프를 고민하면서 현재 환경에 맞는 적절한 선택지를 찾아가는 과정이라 생각합니다.

질문하신 부분에서 Clean architecture를 도입하자고 했어도 사실 그중에 모든 것을 도입할지, 우리조직과 프로젝트에 적합한 일부를 도입할지에 대한 고민도 필요합니다.

실제 개발할 때 완전히 DDD 처럼 쪼개면서 AggregateRoot를 적용하는게 나은 경우도 있고, 그렇지 않은 경우도 있습니다.

추가로 최근에 연관관계 대신에 id를 가져가면 좋다고 이야기하기도 하지만, 이것 또한 장단점이 있습니다.

연관관계가 없으면 매핑도 단순하고 좋아보이지만, 막상 실무에서는 JPA에서 fetch join 같은 좋은 기능을 사용할 수 없는 큰 단점이 있습니다.

결국 DDD에서 설명하는 개념도 그것에 맞는 적절한 프로젝트에서 사용하는 것이지 범용적으로 적용되는 것은 아니라 생각합니다.

연관관계의 경우 제가 선호하는 방식은 가급적 연관관계를 맺어서 사용하되, 업무 도메인 안에서 크게 차이가 나는 부분들이 있다면 이 부분은 개념상 나누어서 연관관계를 끊는 것을 선호합니다. 예를 들어서 주문 관련 테이블들과 결제 정보 관련 테이블들이 있다면 이 둘은 사실 크게 엮여서 사용되지 않습니다. 이런 개념은 사실상 DDD의 bounded context와 유사한데, 이런 경우 둘은 연관관계를 묶지 않고, 단순히 id로만 매핑해서 관계를 끊는 것을 선호합니다. 물론 앞서 말씀드린 것 처럼 각각의 context 안에서는 연관관계를 유지합니다.

cascade의 경우에도 잘못 사용하면 오히려 독이되기 때문에, 코드 몇줄 줄이는 것 보다는 cascade를 제거하는게 더 나은 선택일 수 있습니다. 정말 개인 소유의 경우에 한정해서, 단순한 경우에 사용하는게 맞다 생각합니다.

도움이 되셨길 바래요^^

안녕하세요. pwnable님 좋은 질문입니다.

결론부터 말씀드리면 1,2,3 모두 생각하신 내용이 맞습니다.

cascade는 사실 매우 주의해서 사용해야 합니다. 애매한 경우에는 사용하지 않는 것이 맞습니다.

그러면 cascade를 언제 사용하면 좋을까요?

관련해서 다음 내용을 읽어보시면 도움이 되실거에요.

https://www.inflearn.com/questions/31969

감사합니다.

영한님 답변 감사합니다 :)

남겨주신 링크의 내용 중 DDD의  Aggregate Root와 어울린다 라는 내용이 있었는데요.

이에 대해서 간략하게 영한님의 생각을 듣고 싶습니다.

예전에 회사에서 Clean architecture를 도입하자는 의견이 나왔고 그에 따라 전사적으로 도입한 경험이 있습니다.

물론 좋은 내용의 패러다임이고 장점/단점이 존재하였는데 스타트업 특성 상 인력 교체가 자주 이루어지기 때문에 Clean architecture의 규칙을 계속 유지하기가 상당히 힘들었던 경험이 있습니다.

DDD또한 요즘에는 조금 덜하겠지만 아직도 많은 개발자들에겐 생소한 패턴이라고 생각이 되는데요.

3번 질문 무엇이 좀 더 명시적인가에 대해 영한님 또한 cascase를 사용하지 않는 것이 명시적이다 라고 답변을 주셨는데, 만약 DDD를 도입하여 구현하고 있다고 가정한다면 Cascade 기능을 사용하실건가요?

질문을 간략하게 요약하면, 명시적이지 않은 기능도 특정 패턴 또는 패러다임에 부합할 때는 사용을 해야할까? 에 대한 생각을 듣고 싶습니다!