micro service architecture 에서의 프로젝트명 고민

[jeongph]

따지고보면 MSA 에서 사용하는 각각의 서비스들은 타입은 "service", 목적은 각각의 역할이나 성격 (예를들면 비스니스 서비스명 그 자체거나, 알람전송이나 배치 등 마이크로 서비스 자체의 역할 등)으로 명확히 정해지는데, 서비스 범위? 는 분명하지 않은 경우가 많음 -> 왜냐하면 특정 역할의 서비스는 그냥 다들 참조해서 쓰는 역할이기때문이고, 사실 모두에게 참조당하지 않는 서비스는 별도로 분리하는게 맞나 싶기도 하기때문

예를들어 회원관리 (회원 가입, 로그인, 탈퇴처리, 인증정보 등) 만 해결하는 user service 가 있다고 쳤을 때, 이건 사실상 모든 마이크로 서비스 (그것이 spring 으로 되어있든 django 로 되어있든.. ) 에 참조당하여 사용될 것이기 때문

따라서, 서비스는 앞에 spring, xxTeam, 등의 접두사가 어울리지 않음 -> 그냥 네이밍으로 해도 될것같지만 구분 자체가 어려울 수 있음 (이것이 MSA 기반의 user service 라는) 따라서 고민이 좀 필요한 부분.

[jeongph]

2022-08-09

• 기반 프레임워크 정보는 꼭 필요한것 같다 (e.g. spring, vue, react 등) -> 이래야 무슨 프레임워크 기반으로 작성되었나 알 수 있음
  • 예를들어, 동일한 abc 프로젝트를 back, front 에서 진행시 그냥 "service-abc" 로 하면 얘가 화면인지 API 인지 알 수 없음
• 추가적으로 언어정보를 가지고있는게 좋음 (내 프로젝트의 경우 spring 을 kotlin 기반으로 작성하는 경우가 많기에, kopring 등으로 구분하면 될 것같음)
  • 이건 예를들어 자바를 kotlin 으로 포팅 시 둘다 "spring-playground" 라서 구분 할 방법이 없음