지금 개인 토이 플젝 하고있는데

기존에는 도메인 객체에는 테이블에 매핑할 필드만 쓰고  Entity <-> DTO 정도 변환하는 메서드 정도랑 양방향 관계 있으면 연관관계 맺어있는 객체에 똑같이 값 넣어주는 메서드 정도..?

그 외 나머지는 전부 Service 레이어에 넣었습니다 나머지 검증 로직은 따로 Validate 클래스 만들어서 거기서 검증 로직 짰고, 그게 맞는줄 알고있었는데


우아한 테크코스 채널에서 우아한 객체지향 조영호님 영상 봤는데 엔티티 객체에도 비지니스 로직을 좀 넣으셔서

갑자기 궁금해져서 좀 찾아봤는데 


엔티티 계층은 날씬하고 서비스 계층이 비대하시다면, 서비스 계층의 로직들을 최대한 엔티티 계층으로 끌어내려보시는 걸 추천드립니다. 대부분의 서비스 계층은 결국 엔티티 객체들을 불러와서 메서드들을 호출하는 역할만으로도 충분하다는 것을 발견하실 거예요

엔티티에 비즈니스 로직 몰빵은 잘하고 있는데, 엔티티가 너무 커지고 관심사별로 분리가 잘 안된다고 느끼시나요? Bounded Context 개념을 적용해보세요. 같은 도메인이어도 관심사가 다르면 더 하위의 도메인으로 나뉘어야 합니다.


이런 글을 봤습니다

어찌 생각하시나요?


뭔가 머리에 혼동이와서 정리가 안되네요 ..