아니 근데 왜 다들 요즘 서비스 아키텍처 구상하면서 큰 의문이 들었습니다. 규모가 조금이라도 큰 조직이면 자바나 스프링 강박증이라도 없었다면 높은 확률로 각자가 쓰고 있는 기술 스택이 다를 것입니다. 제가 느낀 위화감이 그것이었습니다. NodeJS, PHP, Java, Go, C++(?) 등으로 이루어진 API 및 웹소켓 서버들이 있습니다. 이 서버들에 대한 공통된 모듈에 대해 항상 큰 의문이 있었습니다.
같은 솔루션에 대한 …
퀀텀이란 무엇인가? 퀀텀은 라틴어 ‘quantus’에서 유래했으며, ‘얼마나 많은’, ‘양의’를 의미합니다. 이외에도 사전 상에서 다음과 같은 의미를 찾을 수 있습니다.
(물리학) 양자: 더 이상 나눌 수 없는 에너지나 물질의 최소 단위. (일반적으로) 최소량, 일정량. 갑작스럽고 중요한 도약을 의미할 때도 사용 아키텍처에서의 퀀텀 아키텍처에서는 사전적 의미의 최소량의 의미를 가지고 쓰이게 됩니다. 일반적으로 한번에 배포될 수 …
배경 로그도 남기고, 이벤트도 남겨? 서비스를 쭉 구성하다보니 이런 생각을 했습니다.
어차피 로그는 남긴다. 필요한 유저 행동에 대해 이벤트르 발행한다. 그러면 각 서비스가 로그에서 필요한 걸 가져가서 상태 변화를 기록하면 되는 것 아닐까? 뭣하러 굳이 이벤트를 별도로 발행하지? 어차피 모두 kafka같은 메시지 브로커를 탈텐데? 왜 굳이 2개를 중복으로 메시지 브로커에게 남겨야 하는가가 매우 큰 궁금증이었습니다.
기본적으로 …
메락아, 그게 무슨 소리니? 아니 일단 들어봐 서비스가 되었든, 소프트웨어가 되었든, 어떤 프로젝트에 대해 보통 기업은 신기술에 밝거나, 손이 빠르거나, 임원의 말을 잘 듣는 사람에게 첫 스타트를 시키는 경우가 많습니다. 하지만 단순히 그렇게 되어서는 서비스나 소프트웨어의 수명이 줄어들어서, 유지보수 비용의 증가 뿐만 아니라 해당 프로젝트를 대체할 새로운 프로젝트를 해야할 수 있어, 큰 지출로 다시 돌아올 수 있습니다.
그래서 …
Liskov Substitution Principle with inheritance 리스코프 치환 법칙은 객체지향 프로그래밍에서 중요한 법칙 중 하나입니다.
서브 타입은 언제나 슈퍼 타입으로 대체될 수 있어야 한다.
개인적으로는 살짝 헷갈린 적이 있는 표현이지만, 코드 내의 인스턴스 타입을 교체하는 케이스로 이해하면 쉽습니다.
상속을 활용한 케이스 이 법칙은 일반적인 상속이 존재하는 객체지향 지향 언어에서 쉽게 설명되는 법칙입 …
개요 코드를 구조화하는 건 생각보다 어렵지 않다고 생각합니다. 하지만 생각보다 어렵기도 하죠. 그래서 사실 이걸 어떻게 표현해야할 지는 모르겠는데, 그냥 편하게 아키텍처를 만드는 것에서 프로젝트 구조를 짜는 것, 코드를 작성하는 것까지의 제 나름대로의 룰을 정리해보려고 합니다.
룰 모듈 혹은 서비스를 분리하세요. 모듈을 서비스와 동치해서 서술합니다.
아키텍처나 프로젝트 전반에서 한번에 거대한 문제를 해결하려고 하지 않습니다. …