2024.09.09 Architecture Disadvantages

 

Lessons Learned From The Trenches Developing Event-Driven Systems

 

Microservices Architecture, The Hard Parts : Trap of Distributed Monolith

백만 명 이하의 유저를  가진 회사는 MSA가 불필요하다.
가지고 있는 문제를 MSA를 통해서 일부 해결이 가능하다면 그것은 애초 설계가 잘못되었다는 것.
기존 문제를 더 많이 해결해야 MSA구조를 사용하라.

메시징 시스템은 이슈가 있을 수 있다. 중복발행, 손실등이 있을 수 있으니 대비해야 한다.
또 메시지 순서도 신경 써야 한다.
재시도의 문제도 있을 수 있다. 여러 시스템에 저장작업을 해야 할 때 재시도를 하면 모든 시스템에 중복 저장이 발생할 수 있다.
분산 트랜잭션등의 개념이 도입되어야 할 수 있다. 이런 단점들을 모두 안고 MSA로 뛰어드는 것이 장점이 있는가?

MAS를 처음 구성할 때는 근사한 이유들이 있지만 규칙들이 지켜지지 않으면 더 높은 제약들을 만나게 됩니다.
서비스들의 경계를 모호하게 정의하거나 너무 많은 동기식 소통, 또 너무 많은 서비스들은 배포의 주기를 늦추게 만듭니다.

따라서 서비스의 경계를 명확하게 정하고 동기보다는 비동기방식을 사용하며 서비스를 많이 늘리지 않고 나중에 분리하는 것입니다.

 

 

 

 

Lean Architecture

이건 앞부분까지만 읽었음

클린 아키텍처가 무엇을 위해서 작성되었는지 생각해야 합니다.
헥사고날 아킨텍쳐나 어니언(이건 모르겠네요) 아키텍처들은 외부종속성 코드 경계나누기를 목적으로 하는데 당신의 프로젝트에 이게 필요한가?
클린을 지키기 위해서는 더 많은 비용과 노력이 필요하게 된다.
아무런 목적 없이 설계를 위한 설계를 하고 있지는 않은가?
소프트웨어를 구축하면서 진정으로 중요한 것 무엇을 염두해야 하는지 생각해 보라.