• 회사에서 개발 시 테스트 커버리지를 체크하나요? 혹시 커버리지 기준 같은 것이 있는지? 커버리지 계산은 어떻게 하는지? 코드리뷰할때 테스트 내용도 같이 보는지? 전체적으로 경험을 듣고 싶습니다.

Q1.
영속성 어댑터 테스트는 실제 데이터베이스를 대상으로 진행해야 한다. Testcontainers 같은 라이브러리는필요한 데이터베이스를 도커 컨테이너에 띄울 수 잇기 때문에 이런 측면에서 아주 유용하다.

Testcontainers 사용해보신 분들 있을까요? 다른 분들은 영속성 어댑터 테스트할 때 어떤식으로 하시는지 궁금합니다.

계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.

책 내용

• ORM 프레임워크를 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받는다. (p. 3)

질문

• 책 내용에서 영속성 관점이라는 것이 정확히 어떤 것을 의미하는지가 궁금합니다.

클린 아키텍처

책 내용

• 가령 Java Persistence API 에서는 ORM 이 관리하는 엔티티에 인자가 없는 기본 생성자를 추가하도록 강제한다.
• 이것이 바로 도메인 모델에는 포함해서는 안 될 프레임워크에 특화된 결합의 예다.

의문점

• 영속성 계층과, 도메인 계층이 하나의 엔티티를 공유하면 @entity, @NoArgsConstructor(access = AccessLevel.PROTECTED) 등의 애노테이션들이 도메인 계층에 침투합니다.
• 하지만 저런 것들을 도메인 계층에서 분리하는 것이 유지보수할때 과연 효율적인지 생각해 볼 문제라고 생각합니다.

질문

• (1) 엔티티를 분리하는 것에 대하여 어떻게 생각하시는지 궁금합니다.
• (2) 엔티티를 분리한다면 JPA 와 같은 ORM 을 사용할 이유가 없다고 생각이 되는데 어떻게 생각하시는지 궁금합니다.

책에서는 아티팩트 분리로 인해 수많은 장점이 있지만 유지보수하는 비용도 그에 따라 증가한다고 합니다.

실제로 저 같은 경우에는 아티팩트를 분리했다가 각각의 아티팩트를 따로 버전관리하느라 얘를 많이 먹었던 기억이 나는데요

과연 아티팩트 분리는 어느 정도가 괜찮다고 생각하시나요?

다들 회사나 팀 내 정책 같은 것이 있나요?

질문

• 계측정 구조란 무엇일까?
• ORM 프레임워크를 사용하는 것이 왜 데이터 베이스 중심적인 아키텍처를 만들게 되는 것일까? ORM 프레임워크를 사용하지 않는다면 데이터 베이스 중식적인 아키텍처를 만들게 되는 문제로 부터 해방이 될까?
• 영속석 모델과 비즈니스 모델의 차이는?
• 상위 계층을 아래로 내려버린다는거 정확히 어떤의미인지 이해가 되지 않는다... 합쳐버린다는건가?

다들 Gradle 멀티모듈을 사용하시나요? Gradle 멀티모듈에서 여러 서버군을 두는 경우에는 application 레이어에서 전 서버군에 해당하는 모든 UseCase가 구현되기 때문에 결국 모든 서버군에 어뎁터 구현체를 조립해야하더라구요..

그래서 application의 port를 별도 모듈로 빼내는 방식으로 처리했는데 혹시 좋은 아이디어 있으신분 있을까요?

질문

• SOLID 원칙이란?
• 인자가 없는 기본 생성자를 추가하도록 강제하는 게 왜 결합의 예일까?

데이터베이스 트랜잭션은 어떻게 해야 할까? 에서 저자가 말했듯이 결국 영속성 영역은 언제 트랜잭션을 열고 닫을지 알 수 없기 때문에 결국은 애플리케이션 영역에서 @Transactional을 사용할 수 밖에 없다고 생각하는데요.

저자는 마지막에 AspectJ를 활용해서 애플리케이션 영역에 @Transactional을 없앨 수 있다고 하네요. 어떻게 할 수 있을지 감이 안오는데 혹시 감오시는 분 계실까요? 아니면 저자가 약파는 걸까요?

5장에서 저자는 컨트롤러에 대해서도 UseCase의 이름에 맞춰서 컨트롤러를 만드는 것을 선호하고 있는데요.

이렇게 되면 사실상 컨트롤러 - UseCase가 1:1인 상태가 될 것으로 보이는데요. 클래스를 잘게 쪼갠다는 점에서 좋아보이긴 하지만 그만큼 관리해야할 클래스가 너무 많아지는 것으로도 보여서요.

도메인 별로 컨트롤러를 구성하면 어떨까 싶기도 한데 어떻게 생각하시나요?

아키텍처를 여러개의 분리된 빌드 아티팩트로 나누는 부분이 나오는데
MSA랑 비슷한 의미로 느껴지는데.... 같은 의미로 봐도 될까요?

질문
저는 헥사고날 아키텍처에 대해서 DDD Lite@Spring session 에서 처음 접했었는데요. 아직 회사 프로젝트중에는 겪어보지 못했네요. 그만큼 런닝커브와 비용이 많이 드는 문제일꺼라 생각해요

1. 혹시 실무에서 해당 아키텍처를 적용한 경우를 겪어보셨다면 후기를 알수 있을까요?
2. open source 로 검색을 해보았던 적이 있는데 너무 다양한 형태의 코드로 포진되어있어서 적당한 플젝을 선정하지 못했는데, 혹시 괜찮은 source code 가 있을까요?

책 내용

• 어플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수 해야 한다.
• 도메인 게층은 영속성 계층을 모르기 때문에 도메인 계층에서 사용한 엔티티 클래스를 영속성 계층에서 함께 사용할 수 없고 두 계층에서 각각 엔티티를 만들어야 한다.

질문

DTO
VO
Entity
Req/Res Param

다른 분들은 각 레이어간 데이터를 어떤 식으로 나누었고, 어떤 명칭으로 사용하고 계신지 궁금합니다.

보다가 궁금해진 내용이 있는데, 여기서는 Entity를 다 분리해서 사용하고 있는데요.
QueryDSL을 사용하게 되면 영속성 어댑터를 어떻게 구현하게 될지 조금 궁금하게 되었습니다.
혹시, 어떻게 사용하면 좋을지 설명 해주실분이 있나요 ㅠㅠ

책에서 스프링 Bean 생성 방법으로 크게 두가지가 나옵니다.

1. 클래스패스 스캐닝 - @component
2. 스프링 자바 컨피그 - @configuration + @bean

각자 선호하시는 스타일이 있는지? 그 이유를 듣고 싶습니다.
그리고 회사에서 팀별로 해당 관련된 정책 같은 것들이 있는지도 궁금합니다.

1. 풍부한 도메인 모델 vs 빈약한 도메인 모델을 보고 전 적절히 섞어서 쓰고 있는걸 확인했는데요. 다른분들은 어떠신가요??
   (빈약한 도메인 모델은 transaction script 를 설명한 것 같은데 이해한게 맞을까요??)

2. 유효성 검사부분 읽으면서 Service layer 에서 @Valid 를 사용할 수 있을까? 찾아보니 이런 글이 있네요
   (https://meetup.toast.com/posts/223)

bean 주입 방법 중에 XML 타입도 있는데 써보신분 계실까요? 책에 안나오는거보면 old 한 방식인걸까요?

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)

영속성 계층은 접해본적이 없어 질문을 하기 어렵네요 ㅎ;;
영속성 계층의 jpaEntity 와 Repository 코드보면서 이렇게 쿼리 날리는 구나.. 알게되었습니다 ㅎㅎ

팀 내에서 컨벤션을 정할 때 매핑에 찬성하는 개발자 vs 매핑에 반대하는 개발자의 논쟁을 했던 적이 있습니다.
당시에는 둘 중 하나만이 팀내 정책이 되어 공통으로 가져가는 것이 좋지 않나 생각했는데 이번 장은 읽으면서 반성을 많이 했습니다.

개인적으로 다른 분들은 팀 별 매핑 전략이 있는지 궁금하네요.

[질문]

• 클래스에 프레임워크에 특화된 애너테이션을 붙여야 한다는 점에서 침투적이다. (p. 114)
• 위 문장에서 침투적이라다는 단어가 나오는데, 평소 침투적인 것을 고려하시면서 개발을 하시나요 ??
• 침투적인것이 나쁜 것인지 ?? 의견을 나누고 싶습니다.

[참고]

• https://www.facebook.com/gyuwon.yi/posts/4888837147826136

의존성 역전 원칙

의존성은 양쪽 코드를 모두 제어할 수 있을 때만 의존성을 역전시킬 수 있다. 만약 서드파티 라이브러리에 의존성이 있다면 해당 라이브러리를 제어할 수 없기 때문에 의존성을 역전시킬 수 없다.

• 프로젝트에서 서드파티를 사용하는 경우 바로 사용하지 않고 서드파티를 컨트롤하는 컴포넌트를 만들어 랩핑하고 컴포넌트의 인터페이스를 통해서만 서드파티에서의 원하는 동작만 가져가는데요. (이렇게 해야 테스트코드 짤때 mocking 하기도 쉽고 서드파티에 대한 의존성도 떨어져서) 책에서 말하는 것처럼 서드파티 라이브러리를 바로 사용하는 경우도 있는지 궁금합니다.

1. 실제 프로젝트를 하면 best-practice 가 무엇일지 많이 찾아보기도 하고 팀 내에서 규칙을 정해 폴더링을 하게되는데요. 책에서는 헥사고날 아키텍처를 기준으로 패키지 기준을 가져갔고 헥사고날 아키텍처를 매우 중요하게 다뤘는데. 각자 어떤 방식으로 패키지 구조를 가져가시는지 궁금합니다.
2. 책에서 의존성 주입의 역할(p.30)에서 중립적인 의존성 주입 컴포넌트의 예시로 초기화를 담당하는 컴포넌트를 들었는데 중립적인 의존성 주입 컴포넌트를 사용할 수 있는 또 다른 예시는 무엇이 있을지 궁금합니다. 사용했던 사례들도 궁금하구요.

컨트롤러 나누기

클래스마다 코드는 적을 수록 좋다. 코드가 적으면 파악하는 것에 난이도가 낮아진다.

모든 연산을 단일 컨트롤러에 넣는 것이 데이터 구조의 재활용을 촉진한다는 데 있다. 그러나 이게 좋을까? 헷갈림만 가지게 될것이다. 따라서, 각 연산에 대해 가급적이면 별도의 패키지 안에 별도의 컨트롤러를 만들며 가급적 메서드와 클래스명은 유스케이스를 최대한 반영해서 지어야 한다. 서로 다른 연산에 대한 동시 작업이 쉬워진다는 것이 가장 큰 장점이다.

책에서는 위와같이, 컨트롤러를 나누는 작업을 이야기 합니다. 저는 서비스도 그렇고 컨트롤러도 그렇고, 간단한 CRUD는 한곳에 모아두고, 그 외적인 유즈케이스가 생길때, 분리하는게 좋다고 생각이 드는데요. 또한 유즈케이스가 연관이 있다면 (예를들면, 회원가입, 로그인) 묶는게 더 좋다고 생각이 들어요.

여러분들은 이 부분으 봤을때 어떻게 느꼈는지 궁금합니다 :)

계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.

• 계층형 아키텍처에서는 도메인 계층은 영속성 계층에 의존하게 때문에, 유스케이스를 만들 때 데이터베이스의 구조를 짜고(table을 만들고) 도메인 코드를 짜는 반면, 클린 아키텍처나 헥사고날 아키텍처는 도메인이 중심이기에 도메인 로직을 먼저 짜고 데이터베이스의 구조를 짜는 걸로 이해했는데요. 실제로 작업하실 때 어떻게 작업하시나요?? 책에서 말하는 이상향은 도메인 로직을 먼저 짜는거라고는 하지만 항상 이상향대로 하는게 쉽지만은 않으니깐요.

딱히 질문할게 없네요...

다른 분들은 현업에서 어느정도로 계층 간 매핑을 활용하시는지 궁금하네요.

저는 Gradle 모듈 설정으로 경계를 쪼개서 아예 잘못된 방향으로 (예를들어 도메인에서 서비스(UseCase)를 사용) 접근하는 것을 막는 것이 가장 최선이라고 생각했었는데요. 다만, 모듈이 패키지는 아니라서 ArchUnit과 함께 체크를 해주는게 좋을거 같다고 생각이 들었어요.

다른분들이 생각하시는 최선의 방안은 어떤걸까요?

p.30 첫번째 단락에 보면
"클린 아키텍처의 가장 본질적인 요건은 2장에서 배웠듯이 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존성을 갖지 않는 것이다.
예제 코드의 웹 어댑터와 같이 인커밍 어댑터에 대해서는 그렇게 하기가 쉽다. 제어 흐름의 방향이 어댑터와 도메인 코드간의 의존성 방향과 같은 방향이기 때문이다."

이 내용이 잘 이해가 안되는데 설명 좀 해주실분?

회사 admin코드에서는 책에서 말한 지름길을 사용한 코드를 리팩토링해야 하는 케이스들이 왕왕 있었습니다. (도메인 엔티티를 입출력 모델로 사용했거나, 컨트롤러 단에서 서비스를 호출하지 않고 레포지토리를 호출하는 케이스)

처음에 봤을 때에는 레거시라고만 생각했는데, 지금 돌이켜보면 결국 처음에는 해당 코드들도 단순 CRUD만 하는 코드이고, admin 영속성 계층과 어댑터 계층에서 사용하는 모델이 일치하는 케이스가 많아 보일러 플레이트 코드를 방지하기 위해 지름길을 택했지 않나 싶습니다.

개인적으로는 이런 케이스도 확장되는 케이스를 많이 봐서 추가 기획으로 수정할 일이 생기면 이런 코드를 볼 때마다 서비스 따로 빼내고 가능하면 객체도 분리하고 있었습니다만, 다른 분들은 어떤 기준으로 이런 코드들을 리팩토링하는지 궁금하네요. (혹은 리팩토링을 하지 않고 놔두는지)

책에서는 컨트롤러는 너무 적은 것보다 너무 많은 게 낫다. 라고 책에서 표현하고 있습니다. (p57)
해당 내용을 읽다가 아래와 같은 궁금증이 생겨 남겨둡니다.

1. 가끔 서비스를 개발하다가 하나의 컨트롤러에서 너무 많은 책임을 가지고 있을 때 쪼개어 개발하기도 하는데, 그때마다 이걸 쪼개는 것이 좋을지 하나로 가져가는 것이 좋을지 고민할 때가 있습니다.
   다른 분들은 컨트롤러를 어느 정도의 크기로 만드는지 궁금합니다.

2. 비슷한 구조의 서비스에서 (요청과 응답은 type 값으로 분리해서 동일한 구조를 가져갈 수 있는 경우) 컨트롤러는 하나로 가져가는 것이 좋을까요, 각 타입 별로 나누어서 가져가는 것이 좋을까요?

105 페이지에 "변경 유스케이스"란 말이 나오는데 이게 어떤 건가요?

보통 테스트 코드는 더 추상적이라서 프로덕션 코드에 비해 파악하기가 어려울 때가 많다. 따라서 특정 프로덕션 코드에 해당하는 테스트 코드를 찾기 어렵다.

라는 글이 있었는데 테스트 코드가 프로덕션 코드에 비해 추상적이다 라는 말은 구현이 없어서 그렇게 말한거겠죠? 테스트 코드는 파악하기 힘들거나 읽기 힘들면 안된다고 생각해서요. 그리고 당연히 프로뎍션 코드보다 파악하기도 쉬워야 한다고 생각해서..

풍부한 도메인 모델 vs 빈약한 도메인 모델 어떤걸 많이 선호하시는지 궁금합니다.
책에서 빈약한 도메인 모델을 다음과 같이 설명했는데

일반적으로 엔티티는 상태를 표현하는 필드와 이 값을 읽고 바꾸기 위한 getter, setter 메서드만 포함하고 어떤 도메인 로직도 가지고 있지 않다.

요게 자료 구조체의 형태(DTO)를 말하는건지 궁금합니다. (변수만 있고 함수가 없는 클래스)

p.42 [생성자의 힘] 절에 나오는 것처럼

생성자를 쓸지 빌더패턴을 쓸지 고민을 많이 하게 됩니다.

예를 들어 유저 같은 경우에 추후에 필드가 늘어날 경우가 많은데

이럴 경우 생성자를 만들어 놓으면 늘어난 필드에 대한 생성자를 새로 생성하거나 이미 있는 생성자를 수정해야하는데

이미 있는 생성자를 수정하는 건 좀 위험하고 새로 생성하면 기존 생성자를 호출하는 부분을 다 다시 확인해야 하는 문제점이 있습니다.

빌더를 쓰면 (롬복 사용) 추가 필드에 대해서 호출하는 쪽에서만 다시 코드를 추가하면 되긴 하는데 놓치는 부분이 생기면서 문제가 생기기도 합니다.

어떤 방법도 딱히 맘에 들지가 않은데 다른 분들은 이런 경우에 어떤식으로 해결하시는지 궁금합니다.

클린 아키텍처의 단점으로 각 영역의 모델을 관리해야하고 모델에 접근하기 위한 매핑이 많아질 수 있다는 점이 있을텐데요.

다른분들은 현재 어느정도까지 매핑을 사용하고 계신지 궁금하네요.

Request 객체를 도메인영역(서비스)으로 끌어와서 그대로 사용하는지? 아니면 각 도메인영역에 접근하기 전에 별도 객체로 매핑을 해서 처리를 하는지 등등..

• p.28 아키텍처를 도식화해서 회의 한다는 내용이 있어서 그려봤는데... 제가 아키텍처 구조/패키지 구조를 제대로 이해하고 그린게 맞을까요?
  

• Hexagonal architecture에서는 port "하나" 당 어댑터 "하나"만 존재하는건가요??

• p.30 포트 인터페이스를 구현한 실제 객체를 누가 애플리케이션 계층에 제공해야 할까?
  포트를 애플리케이션 계층 안에서 수동으로 초기화 하고 싶지는 않다. 애플리케이션 계층에 어댑터에 대한 의존성을 추가하고 싶지는
  않기 때문이다. 이 부분에서 의존성 주입을 활용할 수 있다. 모든 계층에 의존성을 가진 중립적인 컴포넌트를 하나 도입하는 것이다.
  이 컴포넌트는 아키텍처를 구성하는 대부분의 클래스를 초기화 하는 역할을 한다.
  이 부분이 이해가 잘 안되는데 중립적인 컴포넌트가 어떤건지 모르겠고 초기화한다는 의미가 뭔지 이해가 안됩니다........〒▽〒

책에서 양방향 매핑전략에서의 문제점으로

"도메인 모델이 계층 경계를 넘어서 통신하는데 사용된다 (포트가 도메인 객체를 입력파라미터와 반환값으로 사용한다)"

라고 나와있는데 웹계층이 아닌 웹/영속성 모델이 도메인으로 매핑할 책임을 가지고 있으면 (웹모델 -> 도메인)에 의존성이 생기는 거니깐 문제점이 아니라고 생각하는데 올바르게 생각하는 걸까요?

이번 장에서 소개한 계층형 아키텍처의 문제점으로 소개된 내용들에 대해 공감하는 내용도 있었고, 완벽하게 공감하지 못하는 부분이 있었습니다.
제가 고민했던 부분에 대해 다른 분들은 어떻게 생각하시는지 의견을 들어보고 싶습니다.

1. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.

저는 기획안을 받았을 때 다음 순서로 서비스를 설계하고 있습니다.
(1) 기획에 필요한 서비스와 값들을 체크한다.

• 필요한 서비스들이 어떤 것인지 파악한다.
• 클라이언트 단에 어떻게 데이터를 내려줄지 설계한다. (url, req/res param)

(2) 필요한 값에 대해 데이터베이스를 설계한다.
(3) 도메인 로직 설계
저는 도메인 로직 설계 전에 데이터베이스나 웹 계층을 설계하는 것이 당연하다고 생각하고 작업하고 있었는데 필요한 데이터들을 정의하기 전에 도메인 계층을 먼저 설계하는 것이 가능한지 궁금합니다.
다른 분들은 어떤 순서로 작업을 진행하고 계신가요?

2. 동시 작업이 어려워진다.

하나의 영속성에 대해 여러 사람들이 각기 다른 서비스로 제공해야 하는 경우, 영속성 레이어를 한 사람이 담당하고 해당 브랜치를 머지해서 작업한 경우는 있었습니다.

그러나 특정 기능은 동시에 한 개발자만 작업할 수 있고, 같은 서비스를 동시에 편집해야 하는 상황 발생 이 부분은 서비스를 잘게 쪼개고 책임을 분리하면 같은 서비스를 동시에 편집해야 하는 상황을 피할 수 있을 것이라고 생각해서 개인적으로는 공감할 수 없는 부분이었습니다. 이것도 다른 분들의 의견이 들어보고 싶네요!

(책 뒤에 이 내용에 대한 추가적인 설명이 나오려나요..? 책에서 레이어드 아키텍처의 단점을 이야기 하기 위해 극단적 예시를 들었다는 생각이 들었습니다.)

"package-private 접근 수준을 이용해 패키지 간의 경계를 강화할 수 있다" 라는 부분에 대한 질문인데요.

저의 경우는 클래스 생성시에 public 으로만 생성하다 보니 어떤식으로 표현될지 선뜻 와닿지가 않네요.

• p.43 빌더를 사용하면 유효하지 않은 상태의 불변 객체를 만드려는 시도에 대해서는 경고해주지 못한다고 하는데 그러면 빌더는 언제 써야 좋은걸까요? 저는 파라미터가 많을 때 가독성을 높이기 위해 빌더를 사용했던 거 같은데 책에서는 IDE가 충분히 빌더를 사용하지 않더라도 가독성을 높이는데 힌트를 준다고 하니 빌더를 굳이 앞으로 사용할 필요가 없는것인가~ 생각이 들었습니다.

• p.50 읽기 전용 작업을 유스케이스라고 언급하는 것은 조금 이상하다. 라고 책에 나와있는데 왜 이상하죠..?
  위키피디아에 써있는 유스케이스의 정의는 행위자(액터)와 액터가 요구하여 시스템이 수행하는 일의 목표인데,
  계좌 잔고 보여주기는 계좌 소유자에게 게좌 잔고를 보여주기를 목표인 유스케이스가 될 수 없는건가요??

질문
p8. 그림 1.5 에서 헬퍼와 유틸리티를 영속성 레이어로 표시되고 있는데 잘 와닿지 않아서 다른분들은 어떻게 나누는지 질문드려요.
저는 layer 를 나눌때 아래기준으로 나눕니다

• 웹
• 서비스
• 도메인
• 인프라

여기서 helper 라 함은 utility 성으로 간주하고 서비스 레이어로 나누는데, 기능을 잠깐 보조하는 속성의 class 를 영속성에 넣는다는 것이 이상하네요

p6. 그림 1.4의 영속성에 대한 표현이 JPA 에 해당하는 것 같아요. JPA 를 사용함으로서 편리한 부분도 있지만 Repository 와의 강한 결합이 문제될 수 있다고 알고 있는데, 이 부분에 대해서 간단하게 이야기 해보고 싶어요

[질문]

• 책에서 @WebMvcTest , @DataJpaTest 를 통합테스트로 소개를 합니다.
• 저는 위 테스트는 필요한 부분만 가져오는 Slice 테스트로 알고있는데 ... 책 내용이 맞는 내용일까요 ??
• (느낌상으론 스프링에서 정의한 테스트와 테스트 관련 개념과가 살짝 다를 수 있다고는 생각이 듭니다.)

[질문]

• 책에서 소개하는 매핑 전략은 전통적인 레이어드 아키텍처에서도 적용할 수 있을 것 같습니다.
• 예를들어 Controller, Service, Repository 에 각각 DTO 혹은 Entity 를 생성하여 매핑할 수 있을 것 같습니다.
• 현업에서 다들 어떻게 사용하시는지 궁금합니다.

p.61 - 컨트롤러명과 서비스명에 대해서도 잘 생각해봐야 한다. 예를 들어, CreateAccount보다는 RegisterAccount가 더 나은 이름 같지 않은가?
BuckPal 예제에서 계좌를 생성하는 유일한 방법은 사용자가 계좌를 등록하는 방법 뿐이다.

RegisterAccount나 CreateAccount나 비슷한 거 같은데.. RegisterAccount가 더 나은 이름인 것 같다는 것에 여러분들은 동의하시나요??

발표자료를 만들다 보니, 궁금점이 생겨 질문을 같이 남겨둡니다.

질문

2. 여기서 말하는건 유틸리티나 헬퍼는 무엇을 말하는건지 잘 모르겠네요.
3. 사실 어댑터와 포트라는 게 어색한데, 혹시 다른 분들은 굳이? 이렇게 까지 해야할까? 라는 생각을 가지실까요 ㅎㅎ

책에서는 ArchUnit가 헥사고날 아키텍처에서 사용된 예시를 보여주었지만, 레이어드 아키텍처에서도 사용할 수 있는듯 한데요. 혹시 다른 분들은 사내에서 이런 의존성 확인 툴 등을 사용한 경험이 있을까요?

생성자의 힘

4장의 생성자의 힘이라는 내용에서 Builder보다는 생성자를 선호하는 뉘앙스로 나오는데요. 다른분들은 어떻게 생각하실까요?

풍부한 도메인 모델 vs 빈약한 도메인 모델

도메인 모델에 대한 이야기도 나오네요. 핵사고날 아키텍처가 DDD와 잘 맞다는 저자의 생각에 따라 이런 주제가 다뤄지는 것 같은데요.
이 부분에 대해서도 이야기 해보면 좋을거 같아 남깁니다 :)

buckpal
|-- account
		|-- adapter
		|		|-- in
		|		|	|-- web
		|		|		|-- AccountController
		|		|		|
		|		|-- out
		|		|	|-- persistence
	        |		|		|-- AccountPersistenceAdapter
	        |		|		|-- SpringDataAccountRepository
		|		|
		|-- domain
		|		|-- Account
		|		|-- Activity
		|
		|-- application
				|-- SendMoneyService
				|
				|-- port
					|-- in
					|	|-- SendMoneyUseCase
					|
					|-- out
						|-- LoadAccountPort
						|-- UpdateAccountStatePort

위 구조에서 domain은 application에 있어야 하는게 아닐까 싶었는데요. 이렇게 생각한 이유는 저자가 말하는 것처럼 domain 모델을 다른 외부 의존성에서 보호하는 의도라면 application 패키지 내에 domain 패키지로 있어야 그 의도가 드러날꺼라고 생각했기 때문이에요.

다른 분들은 어떻게 생각하시나요??

만약 서비스가 @Transactional 애너테이션으로 오염되지 않고 깔끔하게 유지되길 원하면 AspectJ 같은 도구를 이용해 관점 지향 프로그래밍(aspect-oriented programming)으로 트랜잭션 경계를 코드에 위빙(weaving)할 수 있다.

라는 말이 잘 이해가 안가는데 혹시 설명 해주실 분 계신가요?