Symfony 프로젝트를 구성하는 또 다른 방법

MVC 서비스 아키텍처는 Symfony 프로젝트에서 매우 일반적이어서 유일한 방법처럼 느껴집니다. 간단하고 친숙하며 작동합니다. 그렇지 않을 때까지 말이죠. 프로젝트가 성장함에 따라 균열이 나타나기 시작합니다. 비즈니스 논리는 어디에나 있고, 앱 동작은 불분명하며, 코드 유지 관리가 어려워집니다. 이것이 가장 일반적인 접근 방식이지만 Symfony는 이를 고수하도록 강요하지 않습니다.

더 좋은 방법이 있다면 어떨까요?

---

MVC 서비스 아키텍처 사용에 대한 좌절감

 

도메인 로직은 어디에나 분산되어 있습니다.

프로젝트가 성장함에 따라 비즈니스 로직이 전체 코드 기반으로 확산되는 경향이 있습니다. 컨트롤러, 서비스, 양식, 엔터티 등 프로젝트의 모든 계층에는 결국 도메인 모델의 일부가 포함됩니다. 이로 인해 특정 부분에 집중하기가 점점 더 어려워집니다.

 

프로젝트 경계가 명확하지 않음

아키텍처가 기술 계층을 중심으로 구성되면 프로젝트가 성장함에 따라 다양한 컨텍스트 간의 명확한 경계를 식별하기가 더 어려워집니다. 이러한 명확성이 부족하면 코드와 유지 관리 문제가 긴밀하게 결합될 수 있습니다.

 

프로젝트 행동이 명확하지 않습니다

기본 아키텍처는 기술 계층을 강조하기 때문에 프로젝트의 동작을 이해하는 것이 상당히 어렵습니다. 특정 엔터티가 특정 서비스에 의해 관리되는 것으로 유추하거나 데이터베이스 스키마를 추측할 수 있지만 가장 중요한 측면인 프로젝트의 실제 동작은 불분명하고 암시적입니다.

 

다양한 수명주기

비즈니스 로직이 프로젝트 전반에 분산되어 구현 세부 사항과 혼합되면 독립적으로 발전시키기가 어려워집니다. 시간이 지남에 따라 비즈니스 로직의 수명주기는 구현 세부 사항(예: 프레임워크, 타사 API 또는 데이터베이스)의 수명주기보다 훨씬 길어지는 경향이 있습니다. 이러한 불일치로 인해 종속성에서 사소한 변경 사항이 발생할 때마다 코드의 상당 부분을 다시 작성해야 합니다.

---

아키텍처를 구성하는 더 나은 방법

 

비즈니스 로직 분리

필요할 때 비즈니스 로직에 더 쉽게 집중할 수 있도록 하기 위한 첫 번째 단계는 이를 프로젝트의 나머지 부분과 분리하는 것입니다. 이를 위해서는 도메인 폴더를 만드세요. 이 폴더는 구현 세부 사항에 대한 종속성이 없는 순수 PHP 개체를 사용하여 비즈니스 논리를 모델링하는 프로젝트의 핵심이 됩니다. 프로젝트의 나머지 부분은 이 폴더에 의존하지만 도메인 폴더는 누구에게도 의존하지 않습니다.

도메인 폴더 내에서는 기술적인 목적보다는 도메인 용도에 따라 파일을 그룹화해야 합니다. 이는 여기에 엔터티, 서비스 또는 컨트롤러 폴더가 없고 기능이나 도메인 개념에 해당하는 폴더 이름만 있음을 의미합니다.

 

도메인의 정문

프로젝트에서 가장 중요한 측면은 프로젝트가 하는 일, 즉 처리할 수 있는 작업입니다. 이러한 작업은 프로젝트의 동작을 나타내며 비즈니스 로직에 액세스하는 유일한 방법으로 사용되어야 합니다. 이를 반영하려면 모든 프로젝트 동작을 명시적으로 보여주는 Application 폴더를 만드세요. 예를 들어 프로젝트의 신규 개발자로서 이 폴더를 보면 해당 프로젝트가 무엇을 할 수 있는지 한눈에 이해할 수 있을 것입니다.

 

외부 세계와 연결

App 및 Domain 폴더를 사용하면 비즈니스 로직에 집중하기가 쉬워집니다. 그러나 어느 시점에서는 이 비즈니스 로직이 외부 시스템과 상호 작용해야 합니다. 이를 처리하려면 프레임워크별 코드, 데이터베이스 연결 및 라이브러리와 같은 모든 구현 세부 정보가 포함된 Infrastructure라는 세 번째 폴더를 만듭니다.

Infrastructure 폴더의 파일은 앱 및 도메인 파일에 따라 다릅니다. 예를 들어 App 폴더에서 애플리케이션 핸들러를 호출하거나 Domain 폴더에 정의된 인터페이스를 구현할 수 있습니다.

구체적으로 Symfony에서는 Controller 폴더를 수정하고 어떤 서비스가 어떤 인터페이스를 구현하는지 선언하는 작업이 포함됩니다.

# config/routes.yaml

controllers:
    resource:
        path: ../src/Catalog/Infrastructure/Controller/
        namespace: App\Catalog\Infrastructure\Controller
    type: attribute

 

경계를 밝히세요

프로젝트가 발전함에 따라 비즈니스 로직의 일부 부분이 아키텍처에서 고유한 공간을 차지할 가치가 있다는 것을 알 수 있습니다. 좋은 지표는 동일한 용어가 상황에 따라 다른 의미를 갖기 시작하는 것입니다. 예를 들어 제품이라는 단어는 각각 고유한 모델이 필요한 공장 제품, 창고 제품 또는 전자 상거래 제품을 나타낼 수 있습니다. 신(god) 객체도 좋은 지표가 될 수 있습니다. Symfony 프로젝트에서는 User 클래스에 이런 유형의 문제가 자주 발생합니다.

이런 일이 발생하면 이를 추출하고 비즈니스 로직이 독립적으로 발전하도록 해야 합니다.

일부 상황은 프로젝트의 핵심을 형성하고 다른 상황은 이를 지원합니다. 인증과 같은 일반 컨텍스트는 도메인의 중심이 아니기 때문에 더 간단한 아키텍처를 사용할 수 있습니다

이 그림에서 인증 컨텍스트는 표준 Symfony 구조를 사용하고 주문 및 카탈로그 컨텍스트는 도메인 중심 아키텍처를 사용하며 배송 컨텍스트는 기능 중심 아키텍처를 사용하는 것을 볼 수 있습니다.

 

증분 모듈화

특정 컨텍스트가 독립적으로 확장해야 할 정도로 커지면 이를 별도의 배포 단위로 분할하는 것이 좋습니다.

그러나 이 단계에서는 서두르지 마세요. 프로젝트를 모듈식으로 만드는 것부터 시작하고, 컨텍스트를 개별적으로 확장해야 한다고 판단되면 별도로 배포하세요.
동일한 코드베이스에서 두 팀이 협력하는 데 어려움을 겪는 등 조직적 문제가 발생할 경우에만 코드베이스를 분할하세요.

더 나아가

• 사이먼 브라운 - 모듈형 모노리스

---

개념

이러한 솔루션을 탐색하면서 몇 가지 장인 정신 개념을 적용했습니다. 각 항목에 대해 더 자세히 알아볼 수 있도록 이름을 지정하고 간략하게 설명하겠습니다.

 

유비쿼터스 언어

이 특이한 용어 뒤에는 매우 간단한 개념이 숨어 있습니다. 유비쿼터스 언어는 팀이 도메인 모델을 설명하기 위해 사용하는 어휘입니다. 이 어휘는 문서화되어야 하며 제품 대화, 코드베이스 등 모든 곳에서 일관되게 사용해야 합니다.

구체적으로, 제한된 컨텍스트의 루트에 마크다운 파일을 만들고 제품 담당자, 도메인 전문가, 기술팀을 모아 프로젝트의 각 개념을 정의하세요.

더 나아가

• 에릭 에반스 - DDD - 2장: 의사소통과 언어의 사용
• 마틴 파울러 - 유비쿼터스 언어

 

제한된 컨텍스트

제한된 컨텍스트는 프로젝트 내의 언어 경계를 정의하여 유비쿼터스 언어가 더 이상 정렬되지 않는 시스템 부분을 분리합니다. 컨텍스트 맵 및 이벤트 스토밍과 같은 도구는 이러한 경계를 식별하는 데 도움이 될 수 있습니다.

제한된 컨텍스트는 추상적인 개념입니다. 모듈식 모놀리스의 간단한 폴더부터 마이크로서비스 아키텍처의 클러스터에 이르기까지 다양한 방법으로 구현할 수 있습니다.

더 나아가

• 에릭 에반스 - DDD - 파트 IV: 전략적 설계
• Vaughn Vernon - IDDD - 2장: 도메인, 하위 도메인 및 제한된 컨텍스트
• 마틴 파울러 - 제한된 컨텍스트

 

포트 및 어댑터, 육각형, 양파형 및 클린 아키텍처

이러한 모든 아키텍처는 구현 세부 사항에서 비즈니스 로직을 분리하는 것을 목표로 합니다. 포트 및 어댑터, 육각형 또는 클린 아키텍처를 사용하든 핵심 아이디어는 비즈니스 논리 프레임워크를 독립적이고 테스트하기 쉽게 만드는 것입니다.

이 점을 염두에 두고 구현하면 다양한 구현이 가능하며 가장 적합한 구현은 상황과 선호도에 따라 달라집니다. 이 아키텍처의 가장 큰 장점은 비즈니스 로직을 격리함으로써 훨씬 더 효율적인 테스트가 가능하다는 것입니다.

더 나아가

• Alistair Cockburn - 육각형 아키텍처
• 밥 삼촌 - 클린 아키텍처
• Herberto Graca - DDD, Hexagonal, Onion, Clean, CQRS, … 모든 것을 하나로 묶는 방법

 

비명을 지르는 건축물

비즈니스 로직을 "비명"하기 위해 폴더와 파일을 구성하는 아이디어를 Screaming Architecture라고 합니다. 이 개념은 코드 구조가 프로젝트의 목적을 즉시 명확하게 해야 한다는 점을 강조합니다. 목표는 새로운 개발자가 프로젝트의 기능을 한눈에 이해하는 것입니다.

이 주제에 대한 Bob 삼촌의 기사를 꼭 읽어 보시기 바랍니다. 그의 주택 계획 비교는 특히 통찰력이 뛰어납니다.

더 나아가

• 삼촌 밥 - 비명을 지르는 건축물

 

수직 슬라이싱 아키텍처

수직 슬라이싱은 기능별로 프로젝트를 구성하여 각 기능이 독립적으로 발전할 수 있도록 합니다. 복잡성과 성숙도에 따라 다양한 기능에 다양한 아키텍처를 적용할 수 있습니다.

아이디어는 흥미롭지만 이러한 아키텍처를 효과적으로 구현하고 유지하려면 고도로 숙련된 엔지니어가 필요합니다.

더 나아가

• Jimmy Bogard - 수직 슬라이스 아키텍처
• CodeOpinion - 레이어가 아닌 수직 슬라이스 아키텍처!

---

최종 생각

Symfony 프로젝트를 구성하는 방식은 확장성, 유지 관리성 및 명확성에 큰 영향을 미칩니다. 비즈니스 로직을 분리하고 동작을 명시적으로 지정하면 더 쉽게 이해하고 발전할 수 있는 시스템을 만들 수 있습니다.

이러한 아이디어가 처음이더라도 걱정하지 마세요. 소프트웨어 장인정신은 목적지가 아닌 여정입니다. 처음에는 개념이 너무 어려워 보일 수 있지만 각 개념은 귀하의 비즈니스에 더 많은 가치를 제공하는 데 도움이 될 것입니다.

궁금한 점이 있거나 경험을 공유하고 싶으신가요? 댓글에 남겨주세요! 다음 기사도 기대해주세요 ?

위 내용은 Symfony 프로젝트를 구성하는 또 다른 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!