Inflearn コミュニティ Q&A
投稿した質問数
헥사고날 아키텍처에서의 배치, 시큐리티, 비동기 이벤트 처리는 어떻게 하나요?
作成
·
21
·
編集済み
0
안녕하세요,
이번 강의를 통해 처음으로 DDD와 헥사고날 아키텍처에 대해서 공부하고 있는 사람입니다.
헥사고날 아키텍쳐를 지키면서 배치, 시큐리티, 이벤트 처리 등등 다양한 기술을 어떻게 사용하나요?
제가 공부해본 바로는
1. 배치: 애플리케이션 계층에 배치를 통해 이루어질 api를 만들어두고, 어댑터 계층엔 배치(Job, Step, Writer, Reader등 )에 관한 설정들을 위치하게 한다.
2. 시큐리티: 전부 어댑터에 위치한다.
이벤트 처리: 이벤트는 도메인으로 간주하고 도메인 계층에 위치시키고, 이벤트 리스너는 어댑터 계층에 위치시킨다. 이벤트를 발행시키는 로직은 애플리케이션 계층에 위치하고, ApplicationEventPublisher 같은 경우는 추상화됐다고 판단하고 그냥 사용하거나, 혹은 인터페이스를 따로 만들어서 사용한다.
이정도인데 큰 흐름에서 제가 이해한 게 맞을까요?
특히 궁금한 건 "이벤트가 도메인으로 간주되어도 문제가 없는지" 입니다.
(무조건 도메인이기 보다는 로직을 처리하기 위해 존재하는 dto로 볼 수도 있는 거 아닌가 싶어서요.)
다른 기술들을 헥사고날 아키텍쳐에 적용시킬 때 주의할만한 사항들도 따로 존재를 할까요?
回答 2
0
안녕하세요. 많은 질문을 주셨네요. 🙂
배치 프로세스 자체는 헥사고날을 이용하는 어댑터로 구현하면 됩니다. 배치에서 필요로 하는 애플리케이션 서비스 기능과 관련 도메인은 내부에서 구현하겠죠.
일반 애플리케이션에서 보안, 인증 등은 기본적으로 헥사고날 밖에서 처리하게 되겠죠. 헥사고날 내부에는 보안 검증이 완료된 요청이 전달이 되는게 일반적입니다. 그런데 도메인 레벨에서도 일종의 보안이 필요한 경우도 있습니다. 도메인 모델을 설계하다 보면, 특히 권한과 관련해서 로직이 수립될 수가 있고 이건 도메인의 관심사입니다. 예를 들어 게시글은 작성자와 관리자만 수정할 수 있다 같은 것들은 애플리케이션 내에서 처리되는 것이 자연스럽습니다. 헥사곤 외부의 액터와 어댑터는 항상 완벽하지 않고, 버그가 있을 수도 있고, 악의적인 요청이 침투할 수도 있습니다. 도메인의 정합성과 규칙을 깨뜨릴 수 있는 행위는 헥사곤 내부에서 다루어야 합니다.
이벤트 자체는 아주 기초적인 개념이기 때문에 어떤 것으로 분류한다고 정해져있지는 않습니다. 다양한 종류의 이벤트가 있기 때문이죠.
그중에서 도메인 이벤트를 사용하기로 했다면, 그건 당연히 도메인 내부에 등록하고 가능하면 도메인 계층에서 발행을 합니다. 주문이 접수됐다는 이벤트가 있다면 주문 접수로 상태를 변환하는 로직에서 이벤트가 던져지면 되겠죠.
도메인 이벤트를 받아서 처리하는 곳은 다양합니다. 일차적으로 애플리케이션 내부에서 처리할 수 있습니다. 이벤트 스토밍을 해보면 이런 케이스를 많이 발견할 수 있습니다. 이걸 이벤트로 처리할지, 아니면 직접 호출로 처리할지 등은 고민해볼 주제입니다.
어떤 경우엔 도메인 이벤트를 애플리케이션 밖에서 처리해야 합니다. 어댑터 내부에서 이벤트를 접수해야 하는 경우도 많습니다. 외부 시스템과 연동, 또 트랜잭션 밖에서 처리해야 하는 경우에 많이 사용합니다.
도메인 이벤트 외에도 스프링의 이벤트 시스템을 활용하는 다양한 방법이 있습니다. 또, 이벤트를 다른 시스템으로 전송해야 하는 필요도 있습니다.
이와 관련해서는 클린 스프링의 두 번째 주제에서 설명드릴 계획입니다.
0
안녕하세요, 인프런 AI 인턴입니다. jayuffh22님!
헥사고날 아키텍처와 관련된 다양한 기술 사용에 대해 질문해주셨군요. DDD와 헥사고날 아키텍처는 특히 모듈화와 테스트 용이성을 강조하는 만큼, 다양한 기술들의 위치와 역할을 명확히 이해하는 것이 중요합니다. 언급하신 내용에 대해 추가적인 설명과 함께 답변드리겠습니다.
1. 배치 처리
- 애플리케이션 계층: 배치 프로그램에 의해 실행될 비즈니스 로직을 포함한 API를 제공해야 합니다. 이는 배치 작업이 비즈니스 로직과 비즈니스 룰에 대한 책임을 가져야 한다는 것을 의미합니다.
- 어댑터 계층: Spring Batch와 같은 기술을 사용하면서 Job, Step, ItemReader, ItemWriter 등의 배치 구성 요소를 설정해야 합니다. 이렇게 함으로써 외부 환경에 의한 변경이 애플리케이션 로직에 영향을 미치지 않도록 분리할 수 있습니다.
2. 시큐리티 처리
- 어댑터 계층: 시큐리티와 같은 기술은 대부분 어댑터 계층에 위치하여, 외부로부터의 접근 제어 및 인증, 인가 로직을 처리합니다. 이렇게 하면 도메인 로직과 분리하여 보안을 관리할 수 있습니다.
3. 이벤트 처리
- 도메인 계층: 이벤트 자체는 도메인 이벤트로 간주되어도 문제가 없습니다. 이벤트는 시스템 내의 중요한 상태 변화를 나타내기 때문에 도메인의 일부분으로 볼 수 있습니다.
- 어댑터 계층: 이벤트 리스너는 어댑터 계층에 존재합니다. 이를 통해 외부에서 발행된 이벤트를 받아 처리하여 도메인 로직과는 분리된 형태로 작동할 수 있습니다.
- 애플리케이션 계층: 이벤트를 발행하는 로직은 애플리케이션 계층에 위치하며, ApplicationEventPublisher 등을 통해 이벤트를 발행할 때 이를 추상화하거나, 인터페이스를 통한 사용도 가능합니다.
주의 사항
- 계층 간의 결합도 최소화: 기술이 침투하여 도메인 로직이나 애플리케이션 계층이 특정 기술에 종속되지 않도록 주의해야 합니다.
- 설계의 유연성: 설계가 지나치게 복잡해지지 않도록 하고, 유지보수와 확장이 용이하도록 지속적으로 모니터링해야 합니다.
- 테스트 용이성: 각 계층은 독립적으로 테스트될 수 있도록 구성해야 하며, 각 계층 간의 인터페이스는 테스트 환경에서도 쉽게 사용할 수 있도록 유지해야 합니다.
관련 자료를 통해 더 깊이 있는 이해를 도울 수 있는 링크를 공유드립니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.