MSA 프로젝트에서는 어떤 방법론은 사용하나요?

MSA는 Microservice Architecture로 아키텍처 스타일 중 하나이지 방법론은 아니다.

MSA와 어울리는 방법론이 있다고 생각할 수는 있겠지만 MSA가 방법론까지 제공하는것은 아니다.

그리고 MSA와 Agile은 다른 이야기이다. MSA를  한다고해서 Agile을 꼭 선택해야할 필요는 없다. Agile을 하지 않았다고 해서 MSA를 못하는것도 물론 아니다. 즉 관계가 없다. 어느 정도 어울리는 부분이 있을수는 있겠지만 서로 반드시 필요한 관계는 아니다.

 

그럼 MSA 프로젝트에서는 어떤 방법론을 사용해야할까?

과거와 같이 정보공학? OOAD? CBC?

Monolith때 사용하던 과거의 방법른을 MSA에서는 적용할 수 없는걸까?

또는 과거의 방법론을 적용했을 때 무슨 문제라도 있을까?

 

 

위의 그림에서 파란색으로 되어 있는 MSA에 관련된 Task 외 나머지 Task는 어떠한가? 처음 보는 Task인가?아니다. 자주 보왔던 Task와 산출물일 것이다. 대부분 과거에 했던 Task와 산출물들인데 MSA에서도 저러한 Task와 산출물이 필요한가? 결론 부터 이야기하면 필요하다. 물론 소규모 프로젝트에서는 그렇지 않을수 있지만 중대규모 이상의 프로젝트에서 수십명의 분석설계자 또는 개발자와 함께 일해야하는 경우에는 필요하다. MSA라도 ASIS분석을 안하것인가? TOBE 요구사항 정의를 하지 않을것인가? ASIS 분석부터 단위테스트 및 그 이후의 전개단계까지 불필요한 Task는 없다. 모두 그 나름의 이유가 그대로 사용된다. 오히려 서비스를 잘 나누려면 더 필요할수도 있겠다.

 

ASIS 분석부터 업무흐름 정의를 서비스 식별 전에 둔 이유는 ASIS 와 TOBE 분석이 어느정도 되어 있어야 TOBE 서비스에 대한 판단이 가능하기 때문에 그렇다. 과거 어느 프로젝트에서 이러한 Task들과 관계없이 서비스 정의 워크샾을 했더니 참여한 분석설계자들이 제대로 대답을 하지 못하거나 서비스에 대한 설득이 어려웠다.

화면 정의 스케치는 사실 서비스 정의 큰 관계없이 진행이 가능하지만 워크샾 중 서비스 검증을 위한 관계도 작성 및 서비스 정의 단계에서 서비스별 화면 Owner매핑이 가능하기 때문에 워크샾 이후에 그 Owner 서비스별로 정의/스케치 하는것도 좋다.

 

그리고 데이터모델링은 반드시 서비스 정의 이후에 해야한다. 왜 그럴까?

서비스별로 DB가 분리되며 그에 따른 데이터 정합성이나 분산 트랜잭션 등을 감안해서 데이터모델링해야 하기 때문이다. 설사 서비스별 DB가 분리되지 않는다 하더라도 이제는 더 이상 DB중심이 아닌 서비스중심의 사고를 해야하기 때문이다.