인프런 커뮤니티 질문&답변
작성한 질문수
MSA 구조에서 공통 클래스
작성
·
689
답변 2
0
ㅎㅎ 답변을 좀 늦게 확인했더니, AI가 먼저 답변드렸네요.
일반적인 공통 모듈에 대해서는 아래 AI의 답변을 참고하시면 될 것 같고, 제 강의에서 복붙으로 가져다 쓴 클래스를 기준으로 설명드리면 ...2가지 케이스가 있습니다.
첫째는 도메인 모델에서 중복되는 클래스 IDNAME,Item등입니다. 이런 클래스들은 어느정도 프로젝트 내에서 규정화 되어 있기 때문에 공통클래스로 별도의 baseProject로 생성하여 각 마이크로서비스가 참조하여 사용할 수 있습니다. 그렇지만 엄밀히 말하면 대여의 IDNAME과 회원의 IDNAME은 다른 개념으로 봐야 합니다. 왜냐하면 바운디드 컨텍스트 마다 별도의 유비쿼터스 개념이 틀릴 수 있기 때문입니다. 따라서 각 마이크로서비스의 도메인 객체는 특정 모듈에 의존되거나 종속되지 않는 것을 저는 선호합니다. 따라서 복붙했지만 복붙이후에는 그 도메인에 소속되어 별도의 생명주기로 유지보수되어야 합니다.
두번째는 도메인 이벤트를 전달하기 위해 복붙했던 클래스 들입니다. 이 케이스는 도메인 이벤트를 발행하는 마이크로서비스팀의 기준에 따라 의존되어 변경되어야 할 것 같습니다. 상황에 따라 여러 방식이 있을 것 같지만 강의에서 처럼 pub-sub관계라면 pub하는 측의 공지나 정의를 sub하는 측에서 따라야 할 것입니다.
감사합니다.
0
안녕하세요, 백린이님, 인프런 AI 인턴이에요.
MSA 구조에서 공통 클래스를 다루는 방법은 다양합니다. 일반적으로는 공통 클래스를 별도의 모듈 또는 라이브러리로 분리하여 관리하는 방법을 많이 사용합니다. 이렇게 분리된 공통 모듈은 각각의 MS 서버에서 필요할 때마다 참조하여 사용할 수 있습니다.
또한, 다른 MS 서버들과의 통신을 위한 API 인터페이스를 정의하고 공통 클래스를 활용하여 데이터를 교환하는 경우도 있습니다. 이렇게하면 복붙으로 인한 중복코드를 피하고 재사용성을 높일 수 있습니다.
실무에서는 각 팀이 독립적으로 개발하거나 유지 보수를 하기 때문에 공통 클래스를 분리하여 관리하는 것이 일반적입니다. 이를 통해 코드의 일관성과 유지보수성을 높일 수 있습니다. 감사합니다!
이 말씀이 예를 들어 회원 바운디드 컨텍스트에서는 회원일 수 있지만, 대여 바운디드 컨테스트에서는 (회원 도메인에서 복붙해왔지만) 대여자로 클래스 네이밍을 하는게 좋을 것 같다는 말씀이신거죵?ㅎㅎ