연관되어 있지만 다른 도메인끼리의 소통 방법 논의

[05AM]

이번에 Study 도메인 패키지 내부에서 StudyMember의 기능을 사용하려고 하면서 어떤 방식으로 다른 도메인의 기능을 사용할 지에 대해 고민하며 몇 가지 방법을 시도해보았습니다.
같은 프로젝트지만 헥사고날 아키텍처를 구현하다 보니 결정하기 어려운 부분이 있었습니다.

1. Study에서 StudyMember에 rest api 통신 (사실상 web adapter 사용)

• adapter에 integration이라는 패키지를 만들어 StudyMemberClient 구현체, domain에 StudyMemberService로 studyMember와 관련된 정보를 가져오는 방식
• rest api http 통신이 아닐 뿐 혹시 나중에 도메인 별로 시스템이 물리적으로 분리되면 구현체만 바꿔서 사용 가능할 것 같습니다.

2. Study에 따로 StudyMember Entity를 만들어 정보를 가져옴

• 편한 방법이지만 중복되는 코드가 너무 많음
• 용철님의 study member validation service와 거의 똑같은 내용의 메서드를 작성하고 있는 자신을 발견했습니다. 😢

3. Study와 StudyMember 합치기

지금 제일 유력하게 생각하고 있는 방향

• 사실 스터디 멤버는 스터디에 속한 것이라고 볼수 있음
• StudyMember의 도메인 내의 기능과 Study에서 자체적으로 구현하는 기능이 중복된게 많음
  ex) 스터디에 소속되는지, 관리자인지, 포도알을 보냈는지 여부 확인 등
• 애초에 스터디 멤버 관련 api path도 api/v1/studies/~

이후 검증 로직이 많이 생길텐데 그때마다 중복되는 메서드를 만드는 것보다는 Study 도메인에 List로 StudyMember 도메인을 넣고 (LazyFetch) 필요할때마다 가져오는 것은 어떨까요?

1, 2번은 구현해봤는데 각자 장단점이 있는 것 같습니다. 편하게 의견 주시면 감사하겠습니다!

[zxcv9203]

1. Study에서 StudyMember에 rest api 통신 (사실상 web adapter 사용)

• adapter에 integration이라는 패키지를 만들어 StudyMemberClient 구현체, domain에 StudyMemberService로 studyMember와 관련된 정보를 가져오는 방식
• rest api http 통신이 아닐 뿐 혹시 나중에 도메인 별로 시스템이 물리적으로 분리되면 구현체만 바꿔서 사용 가능할 것 같습니다.

지금의 UseCase를 가져오는 방식이 아닌 adapter 계층으로 옮기자는 말씀이 맞으실까요?
제가 개인적으로 생각하기에는 UseCase와 adapter 계층의 코드가 크게 바뀌어지지 않을 것 같다는 생각이 듭니다.
UseCase를 쓰다가 분리시 해당 UseCase를 Adapter로 교체하는 거랑 큰 차이가 없다고 생각이 듭니다 🤔
지금은 어찌됐건 하나의 애플리케이션으로 관리되는

2. Study에 따로 StudyMember Entity를 만들어 정보를 가져옴

• 편한 방법이지만 중복되는 코드가 너무 많음
• 용철님의 study member validation service와 거의 똑같은 내용의 메서드를 작성하고 있는 자신을 발견했습니다. 😢

검증이 필요하다면 StudyMember 도메인에 요청하도록 구현하도록하는 것은 제한되는 상황인건가요?
만약 가능하다면 StudyMember라는 도메인에 요청을 하는 식으로 구현하면 더 좋을 것 같습니다 👍

그리고 중복코드를 줄이면서 의존성도 줄일 수 있다면 더 좋겠지만 둘 중 하나 선택해야 하는 상황이라면 저는 의존성을 줄이는게 아키텍처의 목적에 더 맞는 방식이라 생각합니다.

3. Study와 StudyMember 합치기

• 사실 스터디 멤버는 스터디에 속한 것이라고 볼수 있음
• StudyMember의 도메인 내의 기능과 Study에서 자체적으로 구현하는 기능이 중복된게 많음
  ex) 스터디에 소속되는지, 관리자인지, 포도알을 보냈는지 여부 확인 등
• 애초에 스터디 멤버 관련 api path도 api/v1/studies/~

이것도 맞는 말씀이라고 생각합니다. 다만, api Path 같은 경우는 중첩 리소스라고 하더라도 애매하다고 생각합니다. 예를 들어 입출금 서비스와 계좌 서비스가 있다고 가정했을때 계좌 관리 서비스가 안된다고 입출금 서비스도 같이 안되면 곤란할 수 있다고 생각합니다.

그래서 각 서비스가 독립적으로 실행될 수 있느냐가 판단의 기준이 되면 더 좋을 것 같습니다.
저는 의존성을 줄이는게 중복 코드를 줄이는 것보다 더 큰 이점을 불러온다고 생각합니다.

이후 검증 로직이 많이 생길텐데 그때마다 중복되는 메서드를 만드는 것보다는 Study 도메인에 List로 StudyMember 도메인을 넣고 (LazyFetch) 필요할때마다 가져오는 것은 어떨까요?

검증 로직이 많이 생긴다는 것에 대해 예시가 있으면 좋을 것 같다는 생각이듭니다.
객체 지향적으로 말씀하신대로 작성하면 충분한 이점은 있다고 생각합니다.
로직을 작성할때도 (스터디 존재 여부를 확인하기 위해 스터디 조회 -> 스터디 멤버 List를 읽기 이런식으로 작성해도 괜찮을거 같네요 (쿼리는 더 비효율적으로 나가겠지만)

개인적으로는 2번, 3번 중에 하나가 나은것 같습니다.

[05AM]

@zxcv9203

답장을 읽다보니 생각의 전제가 다른 것 같다는 생각이 들었습니다.
제가 가정하는 전제는 헥사고날 아키텍처에서 각 도메인이 분리된 물리적인 시스템일 때를 가정해서 다른 도메인 패키지에 있는 클래스는 가져와서 사용하면 안된다고 생각했는데 혹시 용철님은 다르게 생각하시나요?
저번에 논의하던 내용 중에서 다른 도메인 패키지 내부의 클래스를 가져오지 않고 StudyMember에 직접 하위 도메인을 만들어서 사용하시는 방식으로 이해했습니다.
그런데 말씀하신 내용 중에서 usecase를 가져오는 방식, StudyMember 도메인에 직접 요청 등이 독립된 패키지별 구현보다는 다른 도메인을 참고해도 괜찮다는 의미로 받아들여졌습니다.
아니면 현재 도메인 패키지 내부에 하위 도메인이나 usecase로 구현을 하고 사용한다는 의미인지 궁금합니다.

1. Study에서 StudyMember에 rest api 통신 (사실상 web adapter 사용)

지금의 UseCase를 가져오는 방식이 아닌 adapter 계층으로 옮기자는 말씀이 맞으실까요? 제가 개인적으로 생각하기에는 UseCase와 adapter 계층의 코드가 크게 바뀌어지지 않을 것 같다는 생각이 듭니다.

위의 제가 말씀드린 전제에 따라 Study의 infra의 Client 구현체에서 StudyMember의 webAdapter에 있는 코드를 호출하는 방식으로 생각했습니다. (api 형식)

2. Study에 따로 StudyMember Entity를 만들어 정보를 가져옴

검증이 필요하다면 StudyMember 도메인에 요청하도록 구현하도록하는 것은 제한되는 상황인건가요? 만약 가능하다면 StudyMember라는 도메인에 요청을 하는 식으로 구현하면 더 좋을 것 같습니다 👍

Study 도메인에 따로 StudyMember를 구현하는 것일까요 아니면 기존의 StudyMember의 도메인 기능을 사용하는 것일까요?

그리고 중복코드를 줄이면서 의존성도 줄일 수 있다면 더 좋겠지만 둘 중 하나 선택해야 하는 상황이라면 저는 의존성을 줄이는게 아키텍처의 목적에 더 맞는 방식이라 생각합니다.

의존성을 줄인다는 의미가 변경으로써 생성되는 여러개의 클래스를 주입하게 되어 의존성이 늘어나는 것이 문제라고 보시는 걸까요? 아니라면 부연설명을 부탁 드립니다.

3. Study와 StudyMember 합치기

그래서 각 서비스가 독립적으로 실행될 수 있느냐가 판단의 기준이 되면 더 좋을 것 같습니다. 저는 의존성을 줄이는게 중복 코드를 줄이는 것보다 더 큰 이점을 불러온다고 생각합니다.

StudyMember는 Study의 id만 있어도 전반적인 기능이 독립적으로 실행 가능할 것이라 생각되지만, Study는 StudyMember의 기능이 필요한 경우가 많은 것 같습니다. 아래 후술하겠습니다.

이후 검증 로직이 많이 생길텐데 그때마다 중복되는 메서드를 만드는 것보다는 Study 도메인에 List로 StudyMember 도메인을 넣고 (LazyFetch) 필요할때마다 가져오는 것은 어떨까요?

검증 로직이 많이 생긴다는 것에 대해 예시가 있으면 좋을 것 같다는 생각이듭니다. 객체 지향적으로 말씀하신대로 작성하면 충분한 이점은 있다고 생각합니다. 로직을 작성할때도 (스터디 존재 여부를 확인하기 위해 스터디 조회 -> 스터디 멤버 List를 읽기 이런식으로 작성해도 괜찮을거 같네요 (쿼리는 더 비효율적으로 나가겠지만)

검증 로직의 예시는 스터디를 삭제할 때 스터디 멤버의 관리자 여부를 검사하기 / 스터디 상세 조회 시 포도알을 보냈는지 검사하고 안보냈으면 팝업 띄우는 플래그 / 해당 멤버가 스터디의 멤버인지 확인하기 등이 있습니다.
아무래도 개발하다 보면 케이스가 더 늘어날 것으로 예상됩니다.

스터디 조회 -> 스터디 멤버 List 읽기는 사실 여기 적긴했지만 굳이 스터디 조회할 때 멤버를 조회하지 않아도 될 것 같습니다. 그냥 StudyMember에 직접 쿼리하는게 효율면에서도 좋을 것 같습니다.
다만 스터디 멤버 전체에서 처리해야 하는 로직이 있을 때 사용하는 것이 좋지 않을까 싶습니다. 지금 막 떠오르는 예시는 없어서 필요한 경우 추가하면 좋을 것 같습니다.

추가적으로 어떻게 생각하시는지 의견을 여쭙고 싶습니다!

[zxcv9203]

제가 가정하는 전제는 헥사고날 아키텍처에서 각 도메인이 분리된 물리적인 시스템일 때를 가정해서 다른 도메인 패키지에 있는 클래스는 가져와서 사용하> 면 안된다고 생각했는데 혹시 용철님은 다르게 생각하시나요?
저번에 논의하던 내용 중에서 다른 도메인 패키지 내부의 클래스를 가져오지 않고 StudyMember에 직접 하위 도메인을 만들어서 사용하시는 방식으로 이> 해했습니다.
그런데 말씀하신 내용 중에서 usecase를 가져오는 방식, StudyMember 도메인에 직접 요청 등이 독립된 패키지별 구현보다는 다른 도메인을 참고해도 > 괜찮다는 의미로 받아들여졌습니다.
아니면 현재 도메인 패키지 내부에 하위 도메인이나 usecase로 구현을 하고 사용한다는 의미인지 궁금합니다.

찬미님이 말씀하신대로 특정 아키텍처에서 말하는 요구사항들을 다 지키면서 개발하는 것 또한 좋은 방법이라고 생각합니다 👍 (실전에서 제대로 아키텍처를 사용하기 위해서는 정석이 무엇인지 알아야하고 어느 부분을 포기해야하는지 트레이드 오프를 생각할 수 있는 토대가 되기 때문입니다)

여기서 우리가 아키텍처를 사용하는 이유와 좀 더 근본적인 원인에 대해 같이 생각해보면 좋을 것 같습니다.
기존의 레이어드 아키텍처를 사용하고 트랜잭션 스크립트 위주로 개발하던 시기에서 왜 DDD가 중요해지고 이를 잘 표현할 수 있는 헥사고날 아키텍처 같은 아키텍처들이 대두되었는지에 대해 생각해보면 좋을 것 같아요

제가 생각하기에는 각 코드간의 의존성을 줄이는게 핵심이라고 생각이 듭니다. 그래서 특정 정보에 대한 내용을 최소한으로 의존하기 위해 필요한 정보를 담은 도메인 내부의 별도의 읽기 전용 도메인을 만들려고 했습니다.

그리고 서로 다른 도메인 간에는 해당 도메인에게 요청을 통해 책임을 위임하여 역할의 분리를 진행하려고 했습니다. (Study 도메인이 StudyMember 도메인의 세부 구현을 구현을 작성하지 않고 StudyMember 도메인에게 요청하도록)

이때 도메인의 외부 영역으로 통신하기 위해서 adapter 계층으로 요청하고 응답하는 형식으로 이루어지는게 가장 이상적이겠지만 굳이 자기 자신에게 API 요청을 할 필요가 있을까? 라는 의문이 들긴합니다.
사실상 현재 프로젝트에서 여러개의 서버가 나누어질 상황은 굉장히 희박할 것 같은데 너무 과도하다는 생각이 들었습니다.
UseCase로만 통신해도 크게 문제는 안생길거라고 생각이 들었습니다.

위의 제가 말씀드린 전제에 따라 Study의 infra의 Client 구현체에서 StudyMember의 webAdapter에 있는 코드를 호출하는 방식으로 생각했습니다. (api 형식)

물론, 말씀하신대로 작성하는게 굉장히 이상적이라고 생각하긴 합니다.
미래를 생각하여 너무 과도하게 오버엔지니어링을 하는게 아닌가라는 생각이 듭니다.
그리고 사실 개인적으로는 만약 서버를 나누게 되면 이런 상황에서 코드를 개선하는 경험을 하는 것도 좋을 것 같다는 생각이 들긴합니다 🤔

Study 도메인에 따로 StudyMember를 구현하는 것일까요 아니면 기존의 StudyMember의 도메인 기능을 사용하는 것일까요?

저는 이들을 별개의 도메인으로 나눈다면 Study 도메인에서 StudyMember라는 도메인에 요청을 보내는게 맞다는 생각이 듭니다.
하지만 Study가 문제가 발생해도 StudyMember가 독립적으로 무언가를 할 수 없는 상황 (스터디 정보를 볼때 스터디 멤버에 대한 정보는 독립적으로 볼 수 있어야 한다. 와 같은 요구사항)이라면 이 둘을 하나의 도메인으로 묶어 관리하는 것도 좋은 방법이라고 생각합니다.

다만, 이 경우에는 기존의 코드가 싹다 엎어져야 하니 제 생각에는 리팩토링 요소로 두는게 좋을 것 같습니다.
일단 현재 상태로 기능을 구현하고 차후에 진행해야 할 것 같아요

의존성을 줄인다는 의미가 변경으로써 생성되는 여러개의 클래스를 주입하게 되어 의존성이 늘어나는 것이 문제라고 보시는 걸까요? 아니라면 부연설명을 부탁 드립니다.

말씀하신대로 여러개의 클래스를 주입한다도 하나의 의존성이 늘어나는 요소로 볼 수 있을 것 같습니다 👍
하지만 하나에 다 모든 로직을 넣게되면 객체의 책임이 너무 커지면서 소위 말하는 God class라는 객체가 생성될 위험이 높을 것 같습니다.

여기서 말하는 의존성을 줄인다는 의미는 각자의 비즈니스 역할에 맞게 로직을 나눈 상태에서 다른 도메인에 대한 비즈니스 로직 (대표적으로 검증이 포함될 수 있을 것 같습니다.)에 대한 코드를 작성하는 경우 도메인 간의 의존성이 높아질 것 같습니다. (두 도메인 간의 결합도가 강해진다라고 표현하면 더 좋을 것 같네요. 🤔 )

결국 그러면 Study는 다른 도메인인 StudyMember라는 도메인을 나누었지만 서로 자세한 내용을 알게되는 코드들이 작성될 수 있으며, 패키지 구조만 헥사고날 아키텍처를 지향하는 코드가 작성하게 될 위험이 존재할 것 같습니다.

StudyMember는 Study의 id만 있어도 전반적인 기능이 독립적으로 실행 가능할 것이라 생각되지만, Study는 StudyMember의 기능이 필요한 경우가 많은 것 같습니다. 아래 후술하겠습니다.

검증 로직의 예시는 스터디를 삭제할 때 스터디 멤버의 관리자 여부를 검사하기 / 스터디 상세 조회 시 포도알을 보냈는지 검사하고 안보냈으면 팝업 띄우는 > 플래그 / 해당 멤버가 스터디의 멤버인지 확인하기 등이 있습니다.
아무래도 개발하다 보면 케이스가 더 늘어날 것으로 예상됩니다.

넵 그렇기 때문에 도메인을 하나로 합치지 않는 이상 서로 다른 도메인간의 협력이 필요한 상황이라고 생각이듭니다.
이를 해결하기 위해서는 어댑터 계층끼리 통신 vs UseCase 간의 통신이 있을 것 같습니다.

이부분도 개인적으로는 답이 정해진 부분은 아니라고 생각합니다.
어댑터 계층을 통해 코드를 작성하면 그만큼 보일러 플레이트 코드도 많이 생기고 비효율적인 통신들이 맺어질 수 밖에 없기 때문입니다.
물론, 헥사고날 아키텍처에서 지향하는 변화에 유연한 코드를 만드는데 한걸음 더 다가갈 수 있다는 생각이 듭니다.

UseCase를 사용하면 좀 더 과정을 축소화시킬 수 있고 각자의 세부 구현을 직접 작성하는 것이 아닌 요청하여 값을 얻기 때문에 (물론 UseCase의 반환값이 특정 도메인이라면 DTO로 보내게끔 수정할 필요가 있을 것 같습니다.) 통신과정을 간략화 할 수 있다는 장점이 있을 것 같습니다.

하지만, 어댑터를 사용하는 방식에 비해 변화가 발생할 경우 수정해야할 포인트가 많다는 문제가 존재할 것 같습니다.

저는 이 과정에서 이들이 별도의 서버로 분리될 가능성을 거의 없다고 판단하고 UseCase를 이용한 방식을 사용했습니다.

스터디 조회 -> 스터디 멤버 List 읽기는 사실 여기 적긴했지만 굳이 스터디 조회할 때 멤버를 조회하지 않아도 될 것 같습니다. 그냥 StudyMember에 직> 접 쿼리하는게 효율면에서도 좋을 것 같습니다.
다만 스터디 멤버 전체에서 처리해야 하는 로직이 있을 때 사용하는 것이 좋지 않을까 싶습니다. 지금 막 떠오르는 예시는 없어서 필요한 경우 추가하면 좋> > 을 것 같습니다.

추가적으로 어떻게 생각하시는지 의견을 여쭙고 싶습니다!

빠르게 개발하기 위해 UseCase를 통해 처리를 했었는데 다른 도메인이라면 Adapter를 통해 통신하는 방식으로 진행해도 괜찮을 것 같습니다.
도메인을 합치는 것 역시 좋은 선택이지만 이미 작성된 코드가 너무 많아 합치는 부분은 나중에 리팩토링 요소로 생각하는게 좋을 것 같다는 생각이 듭니다 🤔

[05AM]

여기서 우리가 아키텍처를 사용하는 이유와 좀 더 근본적인 원인에 대해 같이 생각해보면 좋을 것 같습니다.
기존의 레이어드 아키텍처를 사용하고 트랜잭션 스크립트 위주로 개발하던 시기에서 왜 DDD가 중요해지고 이를 잘 표현할 수 있는 헥사고날 아키텍처 같은 아키텍처들이 대두되었는지에 대해 생각해보면 좋을 것 같아요

아하 이해했습니다.

제가 생각하기에는 각 코드간의 의존성을 줄이는게 핵심이라고 생각이 듭니다. 그래서 특정 정보에 대한 내용을 최소한으로 의존하기 위해 필요한 정보를 담은 도메인 내부의 별도의 읽기 전용 도메인을 만들려고 했습니다.

저번에 읽기 전용 도메인을 만드시는 것을 보고 완벽한 헥사고날 아키텍처 방식을 지향하신다고 오해한 것 같습니다. 같은 프로젝트 안에서 헥사고날 아키텍처를 구현하기 위해 여러 방안을 고민했는데 오히려 맘이 편합니다!

말씀하신 방법에서 usecase를 사용하는 것도 인터페이스를 가져오는 것이니 결합도가 낮아져 좋은 것 같습니다.
그러면 결론적으로 Study 도메인 내부의 usecase에서 StudyMemberQueryUseCase 등을 가져와서 사용해도 괜찮다고 생각하시는게 맞을까요?

[zxcv9203]

넵 맞습니다.

다만, UseCase에서 StudyMember라는 도메인 객체가 아닌 StudyMemberResponse와 같은 DTO면 더 좋을 것 같다고 생각이 드네요..! 👍

읽기 전용 도메인을 만든 이유도 도메인을 나누었지만 결국 다른 도메인의 도메인을 가져다 쓰는 것을 보고(StudyMember에서 Study 도메인의 구현을 직접 참조하여 사용) 이러면 나누지 않은 것과 차이가 없다 생각해서 결합도를 낮추기 위해 나누게 되었었습니다..!