마이크로서비스아키텍처 설계기준

정말 마이크로서비스아키텍처를 했다고 할수있을까 ? 
 
먼저는 여기는 api의 게이트웨이를 하는 오케스트레이어가없다.
그 흔적으로는 서비스의 특정기능의 트리거 시, 메일이나 문자를 발송는 시스템구성을 따로 떼었다가 api간의 체이닝 덩치가 커지니 그만둔것같다. 
 
' 앞단. Ux이나 클라이언트에서 불리울 서비스기능을 기준애플리케이션 로직을 분리해 여러개의 애플리케이션으로 나눠서 서비스화하고,  분산 배치한다. 그래야 배포, 확장성, 뒷단변경에 자유로울수 있다 ' 
 
마이크로아키텍처를 검색해보면
상품관리 주문관리 유저관리를 쪼갠걸로 예가나온다.
그래서 드는생각.. 어떻게 구성해야 트랜잭션, 네트워크비용, 유연성,  확장성 이 용이한 구성을 할수있을까? 그리고 기준을두고 나눴을때의 api간의 역할은어디까지로 두는게 좋을까? 
 
 
예를들면 게시글과 게시글에 딸린 댓글, 좋아요 슬퍼요등의 리액션이 게시글보다 덩치 보다커질수있고, 게시글과는 다른구조를 충분히 가질수있어 분리하는 구조를 갖게된다고치자. 
 
전체리스폰스를 담당하는 앞단api군,  게시글api군, 게시글의리액션api군이 있다. 
 
후에 게시글리액션으로 정말정말좋아요 라는 부가기능이 들어갔고, 기존리액션과 동일한형태지만, 서비스특성상 특정버전에서만  
 
기존리액션 vs 기존리액션&추가된건 vs 추가된것 
 
만 나눠진다고했을때, 필터링은 어디서 하는게 좋을까? 
 
나는 앞단api에서 리액션api쪽으로 필터링해줘라는 rest를 호출하고, 받아서 그대로 쓰는게 맞다고 생각한다. 
 
이유는 리액션입장에서 rest api를 설계할때, 게시글의 모든리액션을 다주는경우, 리액션종류에따른경우를 디자인하는게 좋기때문이다.
그리고 앞단에서 정해지는 필터링조건이  번전에따른 리액션타입이기때문에, 앞단api 즉 쓰는 쪽에서는 원하는리액션만 요구하는것이 좋다고 생각한다.
무엇보다 재사용되는 부분은 필터링해주는 리액션api이어야한다. 
 
 
 
쪼개진 컴포넌트는 서비스다. 마치 옆팀이만든 api가변경되는데 우리팀에 문제가 없어야하는것처럼말이다. (좀 심한가?ㅎ) 
 
REST API로 그 기능을 외부로 제공,
트랜잭션
메모리,네트워크성능,  
깊은체이닝으로 엮여지는 관계를 피하기위한 중간의 게이트웨이 (담당하는 오케스트레이어만)  
 
쉬우면서도 어렵다..
여튼 많은 고민이 필요하다.