[3주차] 5장 웹어댑터 구현하기 - 김기현

[bluewow]

1. 웹어댑터의 입력모델은 어디에 위치하게 되나요? buckpal 의 예제로 본다면 in/Web 에 controller 와 같이 있으면 될까요??

2. 웹어댑터에서 client 의 입력을 requestbody 로 받았다고하고 requestModel 을 만들었습니다. 이후 application 으로 데이터를 넘겨주기위해 requestCommand 라는 model 을 또 만드는게 맞는걸까요? 책을 읽다보니 web 과 application 의 model 을 다르게 가져가는것 같은데 비효율이 발생하는 것 같습니다. (예제에서는 이부분을 충분히 표현해주지 못하고 있네요 ㅜ)

3. 공부하다보니깐 사실 layered 와 hexagonal 이 크게 차이점이 없는것 같습니다. 쉽게 생각하자 하고 내려다 보니깐 결국은 둘다 application 을 보호하는건 같은 맥락인것 같더라고요. 단 hexagonal 은 port 를 interface 로 강제화해서 프로젝트 덩치가 크더라도 항상 같은 패턴을 유지하게끔 한다는 이점이 있는것 같다는 생각입니다! 이 부분에 대해서 이야기해 보고 싶어요

4. 이건 조금 다른 주제인데 문득 궁금해서 질문드려보아요. 서로다른 domain 의 service 에서 다른 domain 정보가 필요할떄, 예를 들면 article 에서 글을 쓰기위해 user 정보가 필요할때 user 의 repository 에 직접 접근하지 않고, user 의 service layer 에서 값을 가져와야 한다고 생각하는데 이렇게 된다면 비즈니스 로직과 관련이 없는 메서드가 생성되게 됩니다. 이와같은 메서드는 어디에 위치하는게 맞고, 어떤 이름으로 만들어져야 할까요? (최범균님의 DDD start 에 언급된 내용 domainService)

[Wave1994-Hoon]

1. Request/Response DTO 라면 SendMoneyController 클래스에 내부 클래스로 정의해도 좋을 것 같아요

2. 질문이 adpater/in ---> application/port/in 사이에서 입력 모델을 공유하는 것은 비효율적인 것 같다가 맞을까요 ??
   -> 저도 도메인 Entity 만 공유하지 않는다면 두 개는 공유해도 괜찮다고 생각은 들지만, 이 부분은 취향 차이인 것 같아요
   -> 두개를 공유해서 사용할 때, 외부에서 파리미터 이름 등이 변경이 된다면 application/port/in 모델까지 영향을 미치는 케이스가 종종 생길 것 같습니다.

3. 제가 생각하기에 헥사고날과 레이어아키텍처의 가장 큰 차이는 DB 에 접근할 때 도메인 모델의 의존관계 같습니다.
   -> 책 후반부에 좀 더 유연하게 포트/어댑어 패턴 (헥사고날)을 사용하는 방법에 대하여 소개를 하더라고요
   -> 거기에서 adapter/in 은 지름길을 택해도 의존 방향이 바뀌지 않아서 문제는 없지만 adapter/out 은 그렇게 하면 안된다고 말하더라고요
   -> 실제 사내 코드도 adapter/in 에서 usecase 를 호출하지 않고 바로 service 를 호출하는 방식으로 좀 더 심플하게 사용하는 코드도 있었습니다.

4. 말씀해주신 방법으로 구현을 해야 추후 MSA 넘어가면서 도메인 별로 어플리케이션을 쉽게 분리할 수 있어서 좋다고 생각합니다.
   -> 간단한 어플리케이션이면 저 책처럼 엄밀하게 할 필요는 없다고 보고, 회사 메인 비즈니스라면 저 방법으로 하는게 좋지 않을까 생각합니다.
   -> 단순히 비즈니스 로직과 관련이 없다는 관점보다는 user 도메인은 단순히 데이터를 던져주고 받는 쪽에서 가공을 한다면 service layer 에 같이 있어도 상관 없다고 생각합니다.

[bluewow]

광훈님 답변 감사드립니다!
2. 8장내용을 읽고나서 모델이 비즈니스에 대한 유효성 검사가 필요하다면 나누어도 좋을것 같다는 생각을 했어요
3. 10장 내용을 참고하면 좋을것 같군요!