계층화된 아키텍처에서 DDD까지. 나의 마이그레이션 및 모놀리스 절단 경험

오늘은 백엔드 애플리케이션의 아키텍처에 대해 이야기하고 프로젝트를 구성하는 두 가지 널리 사용되는 방식인 Onion과 DDD를 비교해보겠습니다. 첫 번째 접근 방식에 비해 두 번째 접근 방식의 장점과 최근 프로젝트를 육각형 건축으로 전환한 경험에 대해 말씀드리겠습니다. 이 텍스트는 이미 계층형 아키텍처를 사용해본 경험이 있고 더 많은 작업을 원하는 사용자(예: 마이크로서비스 작업 시작)를 위한 것입니다.

계층형 아키텍처부터 시작해 보겠습니다. 어니언 아키텍처라고도 알려진 계층형은 전체 애플리케이션을 여러 계층으로 나누는 아키텍처입니다. 각 레이어에는 고유한 기능과 명확한 목적이 있습니다. 예를 들어, 데이터베이스와의 상호 작용: 이러한 레이어에는 데이터베이스와의 상호 작용을 위한 기능만 포함되어야 하며 다른 것은 포함되지 않아야 합니다. 클라이언트나 다른 기능과의 상호작용이 없어야 합니다.

계층형 아키텍처에는 백엔드에 3개의 주요 계층, 즉 스토리지와의 상호작용, 애플리케이션 로직, 대표 계층이 있는 경우가 많습니다.

다음은 일반적인 3계층 아키텍처입니다. 모든 것이 매우 간단합니다. 요청은 모든 레이어를 통과하여 최종 형식(스토리지의 요청)을 획득하고, 응답은 반환 과정을 거쳐 클라이언트에게 편리한 형식(JSON, XML 등)으로 전환됩니다.

저는 모든 프로젝트와 제가 참여하는 스타트업에서 꽤 오랫동안 이 아키텍처를 사용해 왔습니다. 소규모 프로젝트에서는 이 접근 방식이 실제로 효과가 있고 문제를 일으키지 않지만, 대규모 프로젝트에서는 혼란이 시작됩니다.

계층형 아키텍처의 주요 원칙 중 하나는 다른 레이어를 전혀 변경할 필요가 없도록 모든 레이어를 유사한 레이어로 교체하는 기능입니다. 하지만 현실적으로 프로젝트에 등장하는 개체가 많아질수록 이를 준수하기가 어려워집니다.

처음에는 종속성이 너무 많이 나타나며 제어하기가 점점 어려워집니다. 이는 단일체를 무시한다는 의미입니다(결국 양파는 단일체 아키텍처입니다). 로드가 올바르게 분산되지 않고 애플리케이션에 과부하가 발생했습니다. 또한 레이어가 혼합되기 시작하여 애플리케이션 로직을 분리하는 것이 점점 더 어려워집니다. 애플리케이션 확장이 점점 더 어려워지고, 종속성이 디버깅을 지옥으로 만들고, 개발 속도가 크게 느려집니다. 불에 연료를 추가하는 것은 개발자의 능력을 제한하는 엄격한 아키텍처 패턴입니다. 이 글을 읽고 계시다면 아마도 이미 이런 일을 겪으셨을 것입니다. 저희 프로젝트에서도 같은 상황이 발생했습니다.

분명히 그러한 상황에서는 모놀리스를 잘라내고 다른 아키텍처로 전환하여 보다 자유로운 패턴을 도입해야 합니다. 우리는 DDD를 선택했는데 그것이 확실한 해결책처럼 보였습니다. DDD(Domain Driven Design, 육각형 아키텍처)는 추상화를 기반으로 구축된 마이크로서비스(모놀리식으로 사용할 수도 있음) 아키텍처입니다. 계층화된 아키텍처 작업 경험만 있다면 대략적인 예로 스토리지와의 상호 작용 계층 대신 일반적으로 모든 기술과의 상호 작용 계층이 있는 동일한 3계층 아키텍처를 상상할 수 있습니다. 추상화가 포함된 별도의 레이어. 추상화는 일반적으로 DDD에서 가장 중요한 것입니다. 이러한 추상화와 보조 도구 및 데모 엔터티(템플릿, 다이어그램)는 애플리케이션과 분리되어 있으며 결과적으로 아키텍처는 다음과 같습니다.

계층형 아키텍처에 비해 육각형 아키텍처의 가장 큰 장점은 확장성입니다. 종속성이 적기 때문에 새로운 기능, 새로운 매개변수 및 새로운 기능을 구현하는 것이 훨씬 쉽습니다.

처음에는 이 구조가 완전히 비논리적으로 보였지만 DDD로 전환하는 과정에서 애플리케이션의 가장 낮은 계층에서도 인프라가 완전히 제거되었기 때문에 작성하기가 훨씬 쉬워졌다는 것을 알게 되었습니다. 의존성이 적었습니다. 각 개체에 대한 일종의 비합리적인 안도감과 갑작스러운 행동의 자유도 있었습니다. 이제 이 접근 방식은 계층형 아키텍처보다 훨씬 더 논리적인 것 같습니다.

그러나 프로젝트에 2~3개의 엔터티가 있는 경우 이러한 아키텍처는 의미가 없다는 점을 기억해야 합니다. 왜냐하면 DDD는 종속성이 많은 애플리케이션에서 주로 마이크로서비스 아키텍처로 사용되기 때문입니다. 2~3개의 에센스로 구성된 소규모 애완동물 프로젝트입니다. 어떤 곳에서는 단순한 선형 아키텍처로도 충분합니다. 그리고 일반적으로, 배우기 위해 실험하기로 결정하지 않는 한, 불필요하게 다양한 기술과 방식을 사용하는 것은 나쁜 습관입니다.

추신 그리고 TGC에 푹 빠져야 합니다: https://t.me/dmkjfss

위 내용은 계층화된 아키텍처에서 DDD까지. 나의 마이그레이션 및 모놀리스 절단 경험의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!