문득 드는 생각인데용 ㅎㅎ 계층간에 dto 클레스는 많이 생기는것은 어떻게 생각 하시나요? 크게 요청/응답 , 서비스 레이어의 dto, 도메인 모델 등 .. 많이 생겨서 불필요한 클레스 작성 이름만 변경되고 중복된 클레스 작성이 생길것같은데 어떻게 생각 하시는지 궁금하네요!
과거 영상에서 다루었던 것 같은데, 전 크게 문제라곱 보지는 않습니다! 대신 중요하다고 생각하는 부분은 습관적으로 클래스를 1:1로 유지하지 않도록 조심하는게 중요하다고 생각합니다. 요청/응답 레이어의 클래스는 외부에 의존적인 면이 있기 때문에 분명 내부의 중요 개념 클래스로 전환되거나 변환 시에 1:1이 되지 않고 개념을 점점 구성해가는 느낌이 되기만한다면 이름만 변경되고 중복된 클래스가 적어진다고 봅니다!
봐주셔서 감사합니다! 모듈 자체에 대한 것은 책이나 컨텐츠 보다는 여러 경험 기준으로 만들어간 것 같습니다, 딱히 떠오르는 컨텐츠는 없네요. 이 회사, 저 회사 돌아다니며 경험하고 여러 케이스 보고 상황에 맞는 적절한 패턴을 구축한 것 같습니다! (그래서 모듈 구조를 이렇게 한다! 로 고정 되어있지 않습니다!)
바운디드 컨텍스트로 나눈적은 없습니다. 제가 DDD는 관심이 없고 잘 모르지만, 모듈 구조가 바운디드 컨텍스트 단위로 되는 것은 비효율적인 모듈 구조가 될 수도 있을 것 같습니다. 문맥간 교류가 활발 할 수도 있고 실질적으론 가깝게 처리되어야 할 수도 있기 때문에 충분한 검토 없이 컨텍스트로만 나눈다면 모듈간에 복잡한 참조나 오염 참조나, 구현의 오염도 발생 할 수 있을 것 같아서 그렇습니다. (해당 서비스/시스템에 대해 이해도가 높다면 문제 발생 가능성이 줄어들 수는 있을 것 같습니다) 제 접근법은 잘 모르는 형태의 서비스나 시스템의 경우는 우선 domain 모듈로 시작해서, '구현 형태 / 운영 경험 / 서비스의 사용 양상' 등등을 고려해서 더 구체적이고 군집이 명확한 패턴이 나오면 그때 domain 모듈에서 추출해서 별도 모듈을 구현하는 식으로 접근 하는 것 같습니다. 그렇게 나누면 모듈 안에선 군집된 컨텍스트가 존재 할 수있게 되는 형태일 것 같습니다, 결국 모듈은 문맥보다는 좀 더 상위 계층으로 다루는게 적합하다고 생각합니다. (당연히 제 기준 생각이라 케이스마다 틀릴 수 있어요!) 아마 그래서 보셨던 예제들의 비율도 수치가 그럴 것 같습니다. (서비스 이해도 / 시스템 장악도 등등의 케바케아닐지..) 봐주셔서 감사합니다! :D
![[NHN FORWARD 22] 클린 아키텍처 애매한 부분 정해 드립니다.](http://i.ytimg.com/vi/g6Tg6_qpIVc/mqdefault.jpg)
![[NHN FORWARD 22] 클린 아키텍처 애매한 부분 정해 드립니다.](/img/tr.png)
설계나 구현에 대한 피드백은 정말 어디서도 들을 수 없는데 매 영상마다 너무 잘 보고 있습니다
도움이 된다면 다행이네요! 봐주셔서 감사합니다! :D
문득 드는 생각인데용 ㅎㅎ
계층간에 dto 클레스는 많이 생기는것은 어떻게 생각 하시나요?
크게 요청/응답 , 서비스 레이어의 dto, 도메인 모델 등 .. 많이 생겨서 불필요한 클레스 작성 이름만 변경되고 중복된 클레스 작성이 생길것같은데 어떻게 생각 하시는지 궁금하네요!
과거 영상에서 다루었던 것 같은데, 전 크게 문제라곱 보지는 않습니다!
대신 중요하다고 생각하는 부분은 습관적으로 클래스를 1:1로 유지하지 않도록 조심하는게 중요하다고 생각합니다.
요청/응답 레이어의 클래스는 외부에 의존적인 면이 있기 때문에 분명 내부의 중요 개념 클래스로 전환되거나 변환 시에 1:1이 되지 않고 개념을 점점 구성해가는 느낌이 되기만한다면 이름만 변경되고 중복된 클래스가 적어진다고 봅니다!
오늘도 잘 보고 갑니다!
봐주셔서 감사합니다! :D
좋은 영상 감사합니다!
혹시 core-api,
core-domain 등 모듈을 나누는 기준은 실무에서 고민하면서 재민님께서 확립하신 부분일까요? 아니면 조금이라도 영감을 받은 책이나 기타 컨텐츠 같은게 있으실까요?!
봐주셔서 감사합니다! 모듈 자체에 대한 것은 책이나 컨텐츠 보다는 여러 경험 기준으로 만들어간 것 같습니다, 딱히 떠오르는 컨텐츠는 없네요.
이 회사, 저 회사 돌아다니며 경험하고 여러 케이스 보고 상황에 맞는 적절한 패턴을 구축한 것 같습니다!
(그래서 모듈 구조를 이렇게 한다! 로 고정 되어있지 않습니다!)
예시로 보여주신 레포는 어디에서 볼수 있을까요?
그리고 혹시 모듈 나누실대 바운디드 컨텍스트 별로 나눠 보신적은 없으신가요 ?
저는 이 방식을 선호하는데 예제들을 보면 8:2 비율로 core,api,domain형식으로 나누더라구요
오늘도 영상 잘 보고 갑니다.
해당 프로젝트 코드는 공개 되어있지 않습니다
다른 영상에서 대략적인 구조 설명을 했었는데 그걸 참고하셔도 됩니다
바운디드 컨텍스트로 나눈적은 없습니다.
제가 DDD는 관심이 없고 잘 모르지만, 모듈 구조가 바운디드 컨텍스트 단위로 되는 것은 비효율적인 모듈 구조가 될 수도 있을 것 같습니다.
문맥간 교류가 활발 할 수도 있고 실질적으론 가깝게 처리되어야 할 수도 있기 때문에 충분한 검토 없이 컨텍스트로만 나눈다면 모듈간에 복잡한 참조나 오염 참조나, 구현의 오염도 발생 할 수 있을 것 같아서 그렇습니다.
(해당 서비스/시스템에 대해 이해도가 높다면 문제 발생 가능성이 줄어들 수는 있을 것 같습니다)
제 접근법은 잘 모르는 형태의 서비스나 시스템의 경우는 우선 domain 모듈로 시작해서, '구현 형태 / 운영 경험 / 서비스의 사용 양상' 등등을 고려해서 더 구체적이고 군집이 명확한 패턴이 나오면 그때 domain 모듈에서 추출해서 별도 모듈을 구현하는 식으로 접근 하는 것 같습니다.
그렇게 나누면 모듈 안에선 군집된 컨텍스트가 존재 할 수있게 되는 형태일 것 같습니다, 결국 모듈은 문맥보다는 좀 더 상위 계층으로 다루는게 적합하다고 생각합니다. (당연히 제 기준 생각이라 케이스마다 틀릴 수 있어요!)
아마 그래서 보셨던 예제들의 비율도 수치가 그럴 것 같습니다.
(서비스 이해도 / 시스템 장악도 등등의 케바케아닐지..)
봐주셔서 감사합니다! :D