클린 아키텍처: 어디서부터 시작해야 할까요?

이전 게시물에는 다음 내용이 있습니다.

• 문제 영역: 몇 가지 요구 사항이 있는 ToDo 애플리케이션
• Python과 Python Polylith를 사용하도록 구성된 기본 저장소입니다.

그래서 몇 가지 결정은 내려졌습니다. 우리는 몇 가지 도구를 갖고 있으며 저장소의 모양을 결정했습니다.

제가 Polylith를 좋아하는 이유 중 하나는 무엇을 코딩하고 있는지, 조직의 규모가 얼마나 큰지는 중요하지 않습니다. 두 개 이상의 저장소가 필요한 경우 모든 저장소가 동일하게 보일 것입니다.

FastAPI, Flask 또는 Django를 사용하든, 단일 또는 다중 라이브러리를 구축하든, Celery를 사용하여 백그라운드 작업을 실행하든 저장소 구조는 일관됩니다.

가장 큰 장점 중 하나는 신규 개발자를 위한 간소화된 온보딩 프로세스입니다. Polylith를 이해하고 있다고 가정하면 프로젝트 구조에 빠르게 익숙해질 것입니다. 재사용 가능한 구성 요소는 구성 요소 폴더에 있고, 진입점은 기본 폴더에 있고, 데모 스크립트는 개발 폴더에 있습니다.

엔터티

Uncle Bob의 "The Clean Architecture" 엔터티는 우리 아키텍처의 초석이자 아키텍처의 가장 내부 계층입니다. 따라서 Polylith 엔터티는 구성 요소로 존재해야 합니다.

구성품은 몇 개인가요?

구성 요소 수는 솔루션의 크기와 복잡성에 따라 달라집니다. 하지만 엔티티용 단일 폴리리스 구성 요소부터 시작하는 것이 좋습니다. 이 접근 방식은 특히 소규모 프로젝트의 경우 명확하고 집중된 아키텍처를 유지하는 데 도움이 됩니다.

엔티티에 단일 구성요소를 사용하는 이유는 무엇입니까?

• 이 계층은 전체 애플리케이션의 기본이 되는 핵심 비즈니스 규칙을 캡슐화합니다. 단일 구성요소로 유지함으로써 일관성을 보장하고 중복을 피할 수 있습니다.
• 단일 구성 요소는 다른 모든 레이어에 대한 종속성이 되므로 종속성 관리를 단순화합니다.

타사 종속성을 피하세요.

외부 종속성을 최소화하고 아키텍처 유연성을 향상하려면 엔터티를 표현하기 위해 Python의 표준 라이브러리를 사용하도록 노력하세요. 여기에는 dict, list, enum, 함수, 클래스 및 최신 데이터 클래스와 같은 데이터 구조 활용이 포함됩니다.

Pydantic 또는 Django Models와 같은 타사 라이브러리를 피하는 이유는 무엇입니까?

• 외부 프레임워크에 결합: 이러한 라이브러리에 의존하면 특정 프레임워크에 불필요한 결합이 발생할 수 있습니다.
• 복잡성 증가: 외부 라이브러리로 인해 복잡성이 증가하고 유지 관리 문제가 발생할 수 있습니다.
• 유연성 감소: 외부 종속성을 제한하면 요구 사항이나 기술 변화에 더 쉽게 적응할 수 있습니다.

이러한 원칙을 준수하면 향후 변화에 탄력적으로 대처할 수 있는 강력하고 유지 관리 가능한 아키텍처를 만들 수 있습니다.

ToDo 엔터티

우리의 예는 간단합니다. 핵심 엔터티는 Gordon의 '할 일 항목'입니다. 저장소에 새 구성 요소를 추가할 수 있지만 올바른 이름을 선택하는 것이 중요합니다.

"core" 또는 "main"과 같은 일반적인 이름을 사용하고 싶을 수도 있지만 도메인 컨텍스트 내에서 의미 있는 이름을 선택하는 것이 중요합니다. 이상적으로 이러한 이름은 고객이나 제품 소유자가 사용하는 용어와 일치해야 합니다. 도메인별 이름을 사용함으로써 코드 가독성과 유지 관리성이 향상되어 개발자와 이해관계자 모두가 프로젝트 구조를 더 쉽게 이해할 수 있습니다.

저장소 작업공간 이름은 todo로 정의됩니다. 결과적으로 모든 가져오기는 다음 형식을 따릅니다.

from todo.XYZ import ...
import todo.XYZ

이 예에서는 단순화를 위해 엔터티를 구성 요소 이름으로 사용합니다. 그러나 실제 시나리오에서는 도메인을 반영하는 명명 규칙을 고려하세요. 예를 들어, 애플리케이션이 문서 복구를 중심으로 진행되는 경우 복구라는 구성 요소가 적합할 것입니다. 마찬가지로 게임 애플리케이션에서는 명확성을 위해 토너먼트_엔티티를 사용할 수 있습니다.

Python Polylith로 구성 요소를 만드는 것은 간단합니다.

poetry poly create component --name=entities
poetry poly sync
poetry install # it may be necessary

이렇게 하면 구성 요소 폴더에 Python 패키지가 추가됩니다. 소스 트리의 새 항목은 다음과 같습니다.

./components
└── todo
    └── entities
        ├── __init__.py
        └── core.py
./test/components
└── todo
    └── entities
        ├── __init__.py
        └── test_core.py

python-polylith 도구는 테스트 예제를 생성하는데 이는 좋은 기능입니다. 이 동작은 [tool.polylith.test] 섹션에서 활성화 = true 값을 false로 설정하여 작업 공간.toml 파일에서 변경할 수 있습니다.

새 엔터티 구성 요소에는 __init__.py 및 core.py라는 두 개의 파일이 추가됩니다. 필요에 맞게 core.py 모듈의 이름을 바꿀 수 있습니다. 일반적인 관행은 __init__.py를 통해 패키지의 공개 API를 노출하는 동시에 core.py와 같은 다른 모듈 내에서 내부 조직을 유지하는 것입니다.

요구 사항 중 현재 ToDo 항목은 단 하나의 엔터티입니다.

@dataclass
class TodoItem:
    owner: str
    title: str
    description: str
    is_done: bool = False
    due_date: Optional[date] = None

이러한 간단한 엔터티를 테스트하는 것은 불필요해 보일 수 있지만 최소한 모든 필드의 존재 여부를 테스트하는 것을 선호합니다. 기여자가 적은 소규모 프로젝트에서는 이것이 중요하지 않은 것처럼 보일 수 있지만 개발자가 많은 대규모 프로젝트에서는 심각한 문제를 예방할 수 있습니다. 엔터티에서 단일 필드를 제거하면 애플리케이션의 다양한 부분이 실수로 중단될 수 있습니다.

이 부분에 대한 풀 요청에서 이 엔터티에 대한 몇 가지 기본 테스트를 추가했음을 알 수 있습니다.

일부 테스트가 이미 정의된 상태에서 각 끌어오기 요청에 대한 테스트를 자동으로 실행하는 GitHub 워크플로를 추가할 기회를 얻었습니다.

결론

• 애플리케이션 기본 엔터티
• CI 설정

다음 단계: 지속성에 대해 이야기해 보겠습니다.

위 내용은 클린 아키텍처: 어디서부터 시작해야 할까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!