오늘도 여전한 에러 해결을 위한 노력과 무시하고 개발하는 나, 이벤트기반 마이크로서비스 구축

오늘도 어김없이 아침부터 에러해결을 위한 나의 시도는 계속되었다. 하지만 해결의 실마리는 아직 찾지 못했다. 지금 현 상황에서는 무엇이 문제인지 도저히 감이 안잡힌다.. 차분하게 다시 에러들을 읽어보고 놓친 부분은 없는가 고민하다보니 하루가 다 지나갔다. 값은 존재하나 읽어보지 못하는 이유는 뭘까?  너무 답답해서, 다른 부분을 조금 개발을 진행했는데, 테스트를 할 수 없어서 개발을 진행하는 것도 의미가 있나? 하는 생각이 든다.

 

이 문제를 어서 빨리 해결해야하는데 너무 오래걸릴까봐 걱정이 된다. 나는 시간이 없는데말이다...뒤에 해야할 일들이 많은데, 하고싶은 일도 많고.. 너무 속상하다.. 그래도 꼭 해결하고 말것이다...!!

 

---

이벤트 기반 마이크로 서비스 구축 독서 및 공부

 

책을 사고서 재미나게 보고있는 이벤트 기반 마이크로 서비스 구축. 요즘에는 에러 때문에 책을 못봤는데, 에러와는 상관없이 책을 보는 시간을 예전처럼 무조건으로 확보하고 봐야겠다. 책의 초반부는 이전 EDA에 대한 공부한 내용과 DDD에 대한 앝은? 지식 덕에 어려움 없이 이해하고선(맞지맞지) 하며 읽어 나갔다.

 

경계 콘텍스트는 응집력이 강해야한다. 콘텍스트의 내부 기능은 집약적(intensive)이고 깊이 연관되어 있으며, 통신이 경계를 넘나들지 않고 내부에서 만 일어나야 한다. 그리고 경계 콘텍스트 끼리는 느슨한 결합이 이뤄져야한다.
- 책의 일부분 -

 

책의 DDD 에 대한 내용 중, 경계 컨텍스트에 대한 내용을 보면서, 실제 DDD 를 적용한 거대한 프로젝트가 너무 궁금해졌다.  대부분 설명에서는 장점에 대한 설명은 많지만 이로인한 단점(트레이드오프)에 대한 내용이 없어 과연 어떤 단점이 있을까? 문제점은 없나? 하는 생각이 많이 들었다. 한편으로 DDD 는 개발을 진행하면서 발생하는 문제들을  해결하면서 자연스럽게 생긴 패틴이자 해결책이 된 것이 아닐까? 하는 생각도 들었다. 그래서(개발적인측면에서만 본다면)단점은 없다고 말하지 않을까? 라고 감히 생각해본다.

 

개인적으로는 경계 컨텍스트를 통한 도메인 분할은 MSA가 탄생하게 됬다고 생각한다. 모호한 도메인 경계에 대한 분명한 경계 컨텍스트를 나눔으로써, 문제를 해결하고, 이를 도메인만 분할하는 것이 아닌, 서비스를 분할하는(생각의 확장) 것까지 도달한게 아닐까 하는 생각이다.

 

지금 나만 봐도, 좋은 코드를 공부하기 위해 클린코드와 리팩터링을 보며 좋은 코드에는 패턴이 존재한다는 것을 알게되었다. 이후로는 좀 더 큰 모듈 수준의 규모의 코드에서의 패턴(GoF의디자인패턴)을 공부하게되었고, 더 나아가서는 프로젝트의 구조인 소프트웨어 아키텍처에 대해 공부하게 되었으니 말이다.

 

또한 책에서는 내가 간과시 했던 통신 구조에 대한 설명을 기술요건에 맞춰 설계할 경우, 비즈니스 콘텍스트에 맞춰 설계할 경우를 비교하여 설명한다. 통신 구조에 대해 이야기할 때면, 콘웨이의 법칙을 꼭 언급하게 되는 것 같다.

 

시스템 구조는 그 시스템을 설계하는 조직의 통신 구조를 그대로 따라갈 수 밖에 없다. - 멜빈 콘웨이-

 

나는 이 콘웨이의 법칙을 다른 책에서 봤었는데, 정확히는 어느 책에서 봤는지 기억은 못하겠다. 하지만 이것 하나는 기억한다. 글쎄, 이건 너무 표준화한 것이 아닌가? 하는 생각을 했었다. 당시 나는 프로젝트(모놀리식)을 담당하면서, 유지보수 및 기능개발을 진행하며, 전혀 모놀리틱한 조직의 통신구조를 갖지 못했다고 생각한다. 굳이 조직의 통신구조를 이야기한다면, 나와 사수(해당프로젝트 담당자는 나포함 2명이다.) 각각의 마이크로 서비스가 돌아가고, 필요할 때만 이야기하고 소통하던.. 그 때를 생각하면 그렇다. (내 소통해보려는 노력이 부족하다고 생각도 하지만, 혼자일하는게 편하다는 사수의 태도도 큰 몫을 한것같다.)

 

무튼 이번 책에서도 콘웨이 법칙과 함께 중요한 데이터 통신구조에 대해 인지할 수 있었다. 데이터 통신 구조는 제품을 설계/개발하는 방법에 핵심적인 비중을 차지하지만 이런 구조가 오랫동안 누락된 경우가 많다고 한다. 그리고 이전 회사가 딱! 떠올랐다. 아마도 지난 프로젝트는 통신 구조(사람과 사람, 시스템과 시스템간 등 모든 통신구조)에 문제가 있었던 것은 아닐까.. 하는 생각이 들며, 많고 다양한 생각들이 들었다..