search

cheese10yun / blog-comment

0 stars 0 forks source link

Spring Guide - Directory - Yun Blog | 기술 블로그 #32

Open utterances-bot opened 4 years ago

utterances-bot commented 4 years ago

Spring Guide - Directory - Yun Blog | 기술 블로그

Yun Blog | 기술 블로그

https://cheese10yun.github.io/spring-guide-directory/

Yeh35 commented 4 years ago

구성하는데 애를 먹고 있었는데 정말 감사합니다. 혹시 블로그에 올리신 내용을 참고해서 써도 될까요?

fucct commented 4 years ago

좋은 글 감사합니다

inoDevlog commented 3 years ago

감사합니다!!

banhyuno commented 2 years ago

깔끔한 정리 감사합니다. 정리되기까지 많은 고민이 있으셨을 것 같다는 생각이 듭니다.

KC64ML commented 2 years ago

진짜 좋은 글 정리 감사합니다.

leehyeonmin34 commented 2 years ago

정리 너무 깔끔하게 되어있고 유용할 것 같아요 감사합니다!!

tars-c commented 1 year ago

정말 최고네요!

ChanghwanK commented 1 year ago

도메인 계층형 관련해서 질문있습니다.

Aggregate 하위 도메인들은 어떻게 패키징 하시는 것을 선호하시나요?? 예제에는 Order만 존재하시는데 사실 Order는 주문 -< 주문 옵션 그룹 (사이즈, 색상) -< 주문 옵션(사이즈: 260,270, 색상: RED, GREEN) 와 같이 하위 도메인들이 존재합니다.

이들은 주문과 동일한 패키징 레벨로 하시나요 아니면 Order 하위 패키지로 내리시나요? 의견주시면 감사하겠습니다.

cheese10yun commented 1 year ago

@ChanghwanK 질문 주신 부분에 대한 주관적인 구분은 없습니다. 케이스에 따라서 다를 거 같은데요. 주문에 속하는 하위 그룹이 많은 경우는 패키지로 구분을 해서 명확하게 경계를 지어서 하위 패키지로 관리할 거 같고요 그렇지 않고 하위 객체가 적다고 하면 단일 패키지로 관리할 거 같습니다.

객체가 많다면 하위 패키지로 가는 장점은 그 패키지 자체가 해당 비즈니스에 대한 컨텍스트를 전달해 주는 부분이 큰 이점인 거 같습니다. 신규로 프로젝트에 투입되더라도 하위 패키지로 명확하게 구분되어 있다면 객체의 책임과 역할의 경계를 직관적으로 표현해 주는 부분의 이점이 꽤 크다고 보입니다. 물론 딱딱 맞춰서 이런 경계가 현실에서는 나누기가 어렵다는 건 당연히 있지만요.

yu-so-young2 commented 3 weeks ago

잘 읽었습니다. 패키지 구조 설계 과정에서 고민이 있어 질문 남겨봅니다.

한 프로젝트에서 REST API 기능을 수행함과 동시에 kakfa 토픽 발행과 컨슘까지 모두 수행할 예정인데, 이런 경우 kafka config 설정에 관한 것은 global.infra.kafka.* 에 위치시키되, 실제 토픽 발행/컨슘 로직은 domain 하위에 위치시켜야 할까요?