나는 이전에 Onion Architecture 및 Clean Architecture 와 같은 다양한 애플리케이션 아키텍처 스타일에 대해 길게 썼습니다 . 다른 많은 아키텍처 스타일과 마찬가지로 비즈니스 가치와 논리를 핵심에 집중시키는 동시에 인프라 문제를 가장자리로 밀어냅니다.

둘 다 유지 관리 가능한 응용 프로그램을 개발할 때 탁월한 패턴입니다. 그러나 이러한 애플리케이션은 시간이 지남에 따라 필연적으로 증가하므로 여러 마이크로 서비스와 핵심 비즈니스 시스템을 포함하기 시작합니다. 이것은 우리가 애플리케이션 아키텍처에서 더 큰 것으로 전환할 때입니다.

애플리케이션 아키텍처와 거의 같은 방식으로 우리는 모든 것이 중단되지 않고 환경의 구성 요소를 교체할 수 있기를 원합니다. "교체 가능한" 아키텍처에 대한 이러한 아이디어는 MACH 아키텍처의 기반이 되는 것입니다.

여기에서 MACH가 등장합니다. MACH Alliance 가 주도하는 이 조직은 확장 가능하고 민첩하며 상대적으로 미래 지향적인 소프트웨어 환경을 촉진하는 일련의 아키텍처 원칙을 수립했습니다.

• 독립적으로 개발, 관리 및 확장되는 마이크로 서비스를 사용 하여 비즈니스 기능 구현
• 모든 기능은 A PI를 통해 노출됩니다.
• 컴퓨팅 및 스토리지 측면뿐만 아니라 자동 확장 및 탄력성 측면에서도 C Loud Native 방식 으로 개발
• 프런트 엔드와 백엔드는 전체 플랫폼이 헤드 리스 방식 으로 작동할 수 있다는 점에서 분리되어 언어와 프레임워크에 구애받지 않습니다.

전자 상거래 아키텍처의 예는 다음과 같습니다.

API 계층의 모든 흰색 구성요소는 자체 마이크로서비스를 나타냅니다. 단일 API로 노출되고 버전이 지정됩니다. 통합 레이어는 API 플랫폼과 ERP, CMS 등의 핵심 비즈니스 시스템 간의 중개자 역할을 합니다.

참고: 시스템에 따라 CMS가 도메인의 일부가 될 수도 있습니다. 예를 들어 완전한 MACH CMS는 전사적으로 적합하므로 기존 CMS보다 통합 계층 뒤에 있습니다. 그것은 모두 달려 있습니다.

진정한 마이크로서비스 방식에서 각 서비스는 자체 도메인 정보의 관리인입니다. 예를 들어 결제 서비스가 결제 서비스 제공업체(PSP)와 통합될 가능성이 높더라도 시스템에서 처리하는 모든 결제 기록을 계속 유지합니다.

PSP가 결제 정보 기록 시스템을 유지하더라도 PSP를 사용할 수 없는 경우에도 플랫폼에서 항상 결제 정보를 사용할 수 있습니다. 동시에 나중에 다른 PSP를 선택해도 결제 정보가 손실되지 않습니다.

이점은 무엇입니까?

진정한 MACH 아키텍처를 채택함으로써 얻을 수 있는 주요 이점 중 하나는 주어진 순간에 작업에 가장 적합한 도구를 선택할 수 있다는 것입니다. 고객이 점점 더 디지털화되고 그 어느 때보다 빠르게 이동함에 따라 기업이 민첩성을 유지하는 것이 그 어느 때보다 중요해졌습니다.

플랫폼의 API 우선 특성으로 인해 모든 정보는 자유롭고 저렴하게 사용할 수 있습니다. 이를 통해 광범위한 조사를 수행하거나 기존 시스템을 고가로 수정하지 않고도 새로운 기능을 신속하게 실험하고 프로토타입을 만들 수 있습니다.

전체 API 플랫폼은 지원 핵심 시스템의 추상화 역할을 하여 부족 지식 의 필요성을 줄입니다 . 즉, 결제가 Stripe, PayPal 또는 기타 PSP에서 이행되었는지 여부에 관계없이 결제는 결제입니다. 이것은 그 영향을 과장할 수 없는 수준의 단순성을 도입합니다.

비즈니스 관점에서 MACH 원칙을 구현하는 아키텍처는 더 빠른 반복을 가능하게 하여 더 빠른 혁신을 가능하게 합니다.

단점은 무엇입니까?

주요 단점은 규모가 큰 분산 응용 프로그램, 특히 많은 양의 분리 및 마이크로 서비스를 포함하는 응용 프로그램을 구현하는 것과 관련된 기술적 복잡성입니다.

결과적으로 일관성이 있을 수 있는 많은 수의 서비스를 운영할 때 시스템 전체가 제대로 관찰 가능하고 예기치 않은 일이 발생할 경우 적절한 모니터링 및 경고가 있는지 확인해야 합니다.

플랫폼이 전반적으로 단순함을 추구하지만 MACH 플랫폼을 설계, 개발 및 운영하는 것은 결코 단순하지 않습니다. 따라서 기술적 민첩성은 대가를 치러야 하며, 단순한 솔루션은 덜 기술적인 조직뿐만 아니라 비즈니스 가치가 반드시 빠른 기술 반복 및 혁신에서 나오지 않는 조직에 더 적합할 수 있습니다.

결론

이 기사는 MACH 아키텍처의 주제와 이것이 현대 비즈니스를 가능하게 하는 방법에 대해서만 다룹니다.

여전히 상대적으로 새로운 업계 용어이지만 지난 10년 동안 본 주요 소프트웨어 아키텍처 패러다임의 연속입니다. 예를 들어 마이크로서비스는 중요한 역할을 하며 많은 기업이 여전히 모놀리식 아키텍처에서 마이크로서비스 지향 아키텍처로 마이그레이션하는 과정에 있습니다.

이것은 내 생각에 MACH가 최종 상태가 아니라는 것을 의미합니다. 목적지이며 네 가지 원칙을 구현하면 점차 더 나은 소프트웨어로 이어집니다.