인프런 커뮤니티 질문&답변

기능적으로 여러 모듈이 있을 때 그 사이에 다양한 의존관계가 발생합니다. 크게 애플리케이션 서비스(헥사곤) 사이에 상호 이용이 있을 수 있고, 도메인 엔티티도 연관관계를 가지고 있게 되겠죠.

우선 가능한 지켜야 할 것은 변경이 일어나는 작업은 가능하면 해당 모듈(회원이든, 부서든) 내의 포트를 타고 그 내부의 애플리케이션 로직, 도메인 로직에서 일어나도록 하면 됩니다. 부서쪽 데이터를 수정한다면 마찬가지겠죠. 그때 필요하면 다른 애플리케이션의 포트 인터페이스를 호출해서 사용하면 됩니다. 이건 아무 문제가 없습니다.

어댑터는 환경에 의존적인 기술을 담당하는 경우에 사용하는 것이므로 사실 애플리케이션의 기본 로직이라면 어댑터는 고려하지 않아도 됩니다. 우선은 이 정도로 설명드릴 수 밖에 없는데요.

좀 더 구체적인 예를 들어서 질문해주시면 다시 답변해드릴게요.

안녕하세요, 인프런 AI 인턴입니다. 화이님!

헥사고날 아키텍처에서 도메인 간의 의존성을 관리하는 방법에 대해 고민하고 계시군요. 이는 엔터프라이즈 애플리케이션 설계 시 중요한 결정 사항 중 하나입니다.

일반적으로 헥사고날 아키텍처, 또는 포트와 어댑터 패턴은 시스템의 유연성과 테스트 용이성을 높이기 위해 사용됩니다. 이를 통해 도메인이 서로 긴밀히 결합되지 않도록 하며, 인터페이스를 통해 간접적인 의존성을 주입받는 것이 장점으로 작용합니다.

하지만, 말씀하신 것처럼 동일 프로젝트 내에서 분리될 가능성이 적다면 포트와 어댑터 패턴의 장점이 크게 발휘되지 않을 수도 있습니다. 아래에서 몇 가지 접근 방식을 제안드리겠습니다:

1. 서비스 인터페이스로 주입하기: 만약, 도메인이 크게 분리되지 않고 항상 같은 프로젝트 내에서 유지될 것이 확실하다면, 부서 관련 서비스 인터페이스를 직접 주입받는 것도 효율적인 방법이 될 수 있습니다. 이는 이해하기 쉽고 구현이 간단하기 때문에 유지보수가 용이할 수 있습니다.

2. 포트와 어댑터로 유지하기: 반대로, 프로젝트가 커지거나 도메인들이 독립적인 발전이 필요할 경우를 대비해 포트와 어댑터 패턴을 유지하는 것이 더 유리할 수 있습니다. 이렇게 하면, 도메인이 서로 독립적으로 변경될 수 있어 미래의 구조 변경에 유연하게 대응할 수 있습니다. 특히, 테스트 환경에서 도메인 간의 경계를 명확히 하여 모킹 등 유닛 테스트 시에 유리합니다.

이는 프로젝트의 장기적인 방향성과 규모에 따라 달라질 수 있는 결정사항입니다. 유지보수와 확장 가능성을 함께 고려하여 결정하시면 좋을 것 같습니다.

아래의 유사한 질문과 답변을 보시면서 조금 더 감을 잡으실 수 있을 것이라 생각합니다:

• 의존성 방향과 관련된 질문이 있습니다.
  
• 동일 계층에서 의존성 관리
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.