집중적인 도메인 애플리케이션 생성. Symfony 접근 방식(1부)-PHP 튜토리얼-php.cn

소개

이 글은 심포니 애플리케이션을 구성하는 방법과 가능한 도메인 지향적으로 코드를 작성하는 방법을 설명하기 위해 작성하기로 결정한 시리즈의 첫 번째 게시물입니다.
아래에서 모든 시리즈 부분에서 사용할 흐름도를 찾을 수 있습니다. 각 게시물에서 다이어그램의 구체적인 부분에 초점을 맞추고 관련된 프로세스를 분석하고 어떤 부분이 우리 도메인에 속할지, 그리고 외부 레이어를 사용하여 다른 부분과 분리하는 방법을 감지하려고 노력할 것입니다.

Creating focused domain applications. A Symfony approach (Part 1)

데이터 처리 분석

첫 번째 부분에서는 데이터 추출 및 검증 프로세스에 중점을 둘 것입니다. 데이터 추출 과정에서는 요청 데이터가 JSON 형식으로 제공된다고 가정합니다.

데이터 추출

요청 데이터가 JSON 요청 페이로드 내에 있다는 사실을 바탕으로 요청 페이로드를 추출하는 것은(이 경우 추출은 JSON 페이로드에서 배열을 얻는 것을 의미함) php json_decode 함수를 사용하는 것만큼 쉬울 것입니다.

class ApiController extends AbstractController
{
    #[Route('/api/entity', name: 'api_v1_post_entity', methods: ['POST'])]
    public function saveAction(Request $request,): JsonResponse
    {
        $requestData = json_decode($request->getContent(), true);
        // validate data
    }
}

로그인 후 복사

데이터 검증

데이터의 유효성을 검사하려면 세 가지 요소가 필요합니다.

검증 규칙을 정의하기 위한 것입니다.
요청된 데이터를 유효한 개체로 변환하기 위한 것입니다.
해당 규칙을 기반으로 추출된 데이터를 검증하기 위한 것입니다.

유효성 검사 규칙 정의

첫 번째로, 들어오는 데이터를 나타내는 DTO(데이터 전송 개체)를 생성하고 Symfony 유효성 검사 제약 조건 속성을 사용하여 이 데이터의 유효성을 검사하는 방법을 지정합니다.

readonly class UserInputDTO {
    public function __construct(
        #[NotBlank(message: 'Email cannot be empty')]
        #[Email(message: 'Email must be a valid email')]
        public string $email,
        #[NotBlank(message: 'First name cannot be empty')]
        public string $firstname,
        #[NotBlank(message: 'Last name cannot be empty')]
        public string $lastname,
        #[NotBlank(message: 'Date of birth name cannot be empty')]
        #[Date(message: 'Date of birth must be a valid date')]
        public string $dob
    ){}
}

로그인 후 복사

보시다시피 최근 생성된 DTO 내에서 입력 데이터 유효성 검사 규칙을 정의했습니다. 해당 규칙은 다음과 같습니다.

이메일: 비워둘 수 없으며 유효한 이메일이어야 합니다
이름: 비워둘 수 없습니다
성: 비워둘 수 없습니다
dob(생년월일): 비워 둘 수 없으며 유효한 날짜여야 합니다.

요청 데이터를 DTO로 비정규화

두 번째로 Symfony 노멀라이저 구성 요소를 사용하여 요청 수신 데이터를 DTO에 매핑할 수 있습니다.

class ApiController extends AbstractController
{
    #[Route('/api/entity', name: 'api_v1_post_entity', methods: ['POST'])]
    public function saveAction(Request $request, SerializerInterface $serializer): JsonResponse
    {
        $requestData = json_decode($request->getContent(), true);
        $userInputDTO = $serializer->denormalize($requestData, UserInputDTO::class);
    }
}

로그인 후 복사

위에 표시된 대로 denormalize 메서드가 작업을 수행하고 한 줄의 코드로 DTO를 수신 데이터로 채웁니다.

DTO 유효성 검사

마지막으로 데이터의 유효성을 검사하기 위해 최근 비정규화된 DTO(수신 데이터를 전달함)의 인스턴스를 수신하고 DTO 규칙에 따라 데이터의 유효성을 검사하는 Symfony 유효성 검사기 서비스를 사용합니다.

class ApiController extends AbstractController
{
    #[Route('/api/entity', name: 'api_v1_post_entity', methods: ['POST'])]
    public function saveAction(Request $request,): JsonResponse
    {
        $requestData = json_decode($request->getContent(), true);
        // validate data
    }
}

로그인 후 복사

도메인 식별

지금까지 추출 및 데이터 유효성 검사 프로세스를 네 부분으로 나누었습니다.

JSON 요청 페이로드에서 배열을 추출합니다.
수신 데이터와 해당 유효성 검사 규칙을 나타내는 DTO를 만듭니다.
배열을 유효성 검사 규칙이 포함된 DTO로 비정규화합니다.
DTO를 검증합니다.

이제 질문은 다음 중 어느 부분이 우리 도메인에 속합니까?
질문에 답하기 위해 관련된 프로세스를 분석해 보겠습니다.

1.- 데이터 추출: 이 부분에서는 "json_decode" 함수만 사용하여 들어오는 데이터를 json에서 배열로 변환합니다. 비즈니스 로직을 추가하지 않으므로 도메인에 속하지 않습니다.

2.- DTO: DTO에는 입력 데이터와 관련된 속성과 해당 속성의 유효성을 검사하는 방법이 포함되어 있습니다. 이는 DTO에 비즈니스 규칙(검증 규칙)이 포함되어 있으므로 도메인에 속한다는 의미입니다.

3.- 데이터 비정규화: 이 부분에서는 단순히 인프라 서비스(프레임워크 구성 요소)를 사용하여 데이터를 객체로 비정규화합니다. 여기에는 비즈니스 규칙이 포함되어 있지 않으므로 우리 도메인에 속하지 않습니다.

4.- 데이터 유효성 검사: 데이터 비정규화 프로세스와 마찬가지로 데이터 유효성 검사 프로세스에서도 인프라 서비스(프레임워크 구성 요소)를 사용하여 수신 데이터의 유효성을 검사합니다. . 이는 DTO에 정의되어 있으므로 비즈니스 규칙을 포함하지 않으므로 도메인에도 속하지 않습니다.

마지막 사항을 분석한 후 DTO만 우리 도메인의 일부가 될 것이라는 결론을 내릴 수 있습니다. 그러면 나머지 코드는 어떻게 할까요?

애플리케이션 서비스 생성

개인적으로 저는 이런 종류의 프로세스(데이터 추출, 비정규화, 검증)를 애플리케이션 계층이나 서비스 계층에 포함시키는 것을 좋아합니다. 왜?, 애플리케이션 레이어를 소개하겠습니다.

애플리케이션 계층

간단히 말하면 애플리케이션 계층은 조정과 조정을 담당하고 비즈니스 로직은 도메인 계층에 맡깁니다. 또한 도메인 레이어와 프리젠테이션 레이어(UI), 인프라 레이어 등 외부 레이어 사이의 중개자 역할을 합니다.
위 정의에서 시작하여 추출, 비정규화 및 검증 프로세스를 애플리케이션 계층의 서비스에 포함할 수 있습니다.

수신되는 데이터 프로세스를 조정합니다.
인프라 서비스(PHP JSON 기능, Symfony 정규화 구성 요소 및 Symfony 검증 구성 요소)를 사용하여 수신 데이터를 처리합니다.
DTO를 검증 인프라 서비스에 전달하여 도메인 규칙을 적용합니다.

좋습니다. 이 프로세스를 관리하기 위한 애플리케이션 서비스를 만들겠습니다. 우리는 그것을 어떻게 할 것인가? 책임을 어떻게 관리할 것인가?

책임 분석

SRP(단일 책임 원칙)에서는 각 클래스가 애플리케이션 동작의 한 부분만 책임져야 한다고 명시합니다. 클래스에 여러 가지 책임이 있는 경우 이해, 유지 관리 및 수정이 더 어려워집니다.

이것이 우리에게 어떤 영향을 미치나요? 분석해 보겠습니다.
지금까지 우리는 애플리케이션 서비스가 수신 데이터를 추출, 비정규화 및 검증해야 한다는 것을 알고 있습니다. 이를 알면 다음과 같은 책임을 쉽게 추출할 수 있습니다.

데이터 추출
데이터 비정규화
데이터 유효성 검사

이러한 책임을 3가지 서비스로 나누어야 하나요? 나는 그렇게 생각하지 않습니다. 설명드리겠습니다.

본 바와 같이 각 책임은 인프라 기능 또는 구성 요소에 의해 관리됩니다.

책임 추출: PHP json_decode 함수
데이터 책임 비정규화: Symfony 노멀라이저 구성 요소
데이터 책임 검증: Symfony 검증 구성 요소

애플리케이션 서비스가 이러한 책임을 인프라 서비스에 위임할 수 있으므로 보다 추상적인 책임(프로세스 데이터)을 생성하여 이를 애플리케이션 서비스에 할당할 수 있습니다.

class ApiController extends AbstractController
{
    #[Route('/api/entity', name: 'api_v1_post_entity', methods: ['POST'])]
    public function saveAction(Request $request,): JsonResponse
    {
        $requestData = json_decode($request->getContent(), true);
        // validate data
    }
}

로그인 후 복사

위에 표시된 것처럼 DataProcessor 애플리케이션 서비스는 json_decode 함수와 Symfony 노멀라이저 및 유효성 검사기 서비스를 사용하여 입력 요청을 처리하고 검증된 최신 DTO를 반환합니다. 따라서 DataProcessor 서비스는 다음과 같습니다.

입력 데이터 처리와 관련된 모든 작업을 조정합니다.
도메인 비즈니스 규칙(DTO)을 통해 외부 세계(인프라 서비스)와 통신합니다.

알다시피, 유효성 검사 프로세스에서 오류가 발견되면 DataProcessor 서비스에서 Symfony ValidationException이 발생합니다. 이 시리즈의 다음 게시물에서는 비즈니스 규칙을 적용하여 오류를 구조화하고 최종적으로 클라이언트에게 제시하는 방법을 알아봅니다.

DataProcessor 서비스를 제거하고 MapRequestPayload를 서비스 애플리케이션 계층으로 사용하여 데이터를 추출, 비정규화 및 검증할 수 있다는 것을 알고 있지만 이 기사의 맥락을 고려할 때 다음이 더 편리하다고 생각했습니다. 이렇게 쓰세요.

결론

이 첫 번째 기사에서는 흐름도에서 데이터 추출 및 검증 프로세스에 중점을 두었습니다. 우리는 이 프로세스와 관련된 작업을 나열했으며 어떤 부분이 도메인에 속하는지 검색하는 방법을 배웠습니다.
어떤 부분이 도메인에 속하는지 파악하여 도메인이 관리하는 인프라 서비스를 연결하고 데이터 추출 및 검증 프로세스를 조정하는 애플리케이션 계층 서비스를 작성했습니다.
다음 기사에서는 예외를 관리하기 위한 비즈니스 규칙을 정의하는 방법을 살펴보고 입력 DTO를 지속 가능한 엔터티로 변환하는 일을 담당하는 도메인 서비스도 만들 것입니다.

위 내용은 집중적인 도메인 애플리케이션 생성. Symfony 접근 방식(1부)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!