MSA 기반 물류관리 및 배송시스템 프로젝트를 마치며...

물류 관리 및 배송 시스템을 위한 MSA 기반 플랫폼 개발

나는 Security 파트와 User파트를 맡았다.

 

 

프로젝트를 마치며 튜터님께 피드백이 온것들을 정리해보겠습니다.

 

인프라설계서

 

MSA 서비스 중 Object Service 는 서비스 명을 보고도 해당 서비스가 어떤 역할을 할지를 유추할 수 있는 이름으로 변경하시면 좋습니다. 대면피드백때도 말씀드린 내용인데요! Object Service 의 root 에그리거트 이름을 따라가면 좋습니다 :) 

Object라는 서비스 명이 직관적이지가 않다는 피드백을 받았습니다. Object안에 Hub관리 도메인들이 있었기에, Hub Service로 이름을 수정하는 방향을 생각했다.

 

 

 *Gateway 에서 Auth 서비스를 호출할 때에 localhost 로 Auth 서비스를 호출하고 계신 것 같습니다.

해당 부분을 FeignClient 으로 호출하도록 변경하면 추후 Auth 서비스가 확장되서 여러개의 서버로 동작할 때, FeignClient 의 로드벨런싱도 자동으로 적용할 수 있는 장점이 있습니다.

 WebClient로 uri에 localhost로 Auth서비스를 호출하였는데, 그 부분을  FeignClient로 수정하는 방향을 생각하였다.일단 Gateway-auth서비스의 구조는Auth서비스의 토큰검증api를 만들어놓은후, Gateway 에서 검증api를 호출하여 검증을 수행하는 구조이다.

 

auth 서비스 구조는JWT 발급 및 검증API를 제공하고, 로그인시 JWT를 발급하며, 검증api를 통해 클라이언트가 보낸 JWT가 유효한지 확인하는 구조이다.

 

* OrderService:87 에서 Entity 의 Setter 를 사용하여 객체를 업데이트 해주고 있는 것을 확인했습니다.

DDD의 관점에서 엔티티는 자신의 상태를 스스로 관리해야 하며, 엔티티 내부 함수로만 상태 변경이 이루어져야 합니다.

이유는 Setter를 통해 외부에서 임의로 상태를 변경하면, 도메인 규칙이나 비즈니스 로직을 위반할 위험이 있어 엔티티의 무결성을 잃을 수 있기 때문입니다. Order 엔티티 내에 public void update() 함수로 구현하시면 더 좋습니다 :) * 위 내용과 같은 이유로 서비스에서 Builder 로 엔티티 객체를 생성하는 것도 지양하시는 것이 좋습니다.

 

예를 들어, 주문 금액이 생성되거나 변경될 때마다 주문 금액을 한글로 표현하는 String koreanPrice 변수가 있다고 가정해봅시다. 주문이 생성되거나 수정될 때마다 해당 규칙을 적용해야 하는데, 서비스 계층에서 Builder 패턴을 사용해 엔티티를 생성하거나 setter 를 이용해서 엔티티를 수정한다면, 도메인 규칙이 외부로 분산되게 되어 유지보수 및 디버깅이 어려워질 수 있습니다. * FeignClient 구현체 = '인프라스트럭처 계층' (외부요청 이기에) FeignClient Interface = '응용 계층' ( DIP를 위함 ), FeignClient 에서 사용하는 DTO = '응용 계층' 으로 변경이 필요합니다!