[230314] Polylith 00
Table of Contents
1 모듈별 설명
1.1 Library
라이브러리는 자체 네임스페이스에 있는 코드조각. 이름충돌 없이 사용할 수 있어야 한다. 우리는 이미 사용하는 도구에 의존하여 다른 라이브러리에 대한 종속성을 해결하고 디스크에 파일을 캐싱하는 복잡성을 숨긴다.
1.2 Component
레이어(수평, 수직, onion)의 필요성을 없애주는 상위 수준의 빌딩 블록. 컴포넌트는
- 도메인의 일부(장바구니, 인보이스, 주문, 사용자 등)를 나타내거나
- 당사 인프라의 일부(인증, 데이터베이스, 로그)
- 서드파티와 통합하는 지점(crm-api, 결제-api, sms-api)
1.3 Base
REST, Lambda, Graphql, gRPC, command line 등 공용 API를 통해서만 기능을 노출하는 툭수향 빌딩 블록
베이스는 API를 통해 엔드포인트 모음을 노출한다. 각 엔드포인트의 구현을 적절한 컴포넌트에 위임한다.
1.4 Brick
브릭은 (라이브러리와 함께) component 또는 base의 일반적인 이름
1.5 Project
프로젝트는 service, lambda function, command line tool 또는 새로운 라이브러리 등에서 어떤 라이브러리와 브릭을 아티팩트에 포함할지 결정한다.
이를 통해 여러 프로젝트에서 컴포넌트를 최적으로 코드재사용을 할 수 있다.
1.6 Development Project
모든 라이브러리, 컴포넌트 및 베이스로 작업하는데 사용하는 공간. 전체 코드베이스에서 전체 코드 탐색, 디버깅 및 리팩터링이 가능한 '모놀리식 개발 환경'을 제공하며 단일 REPL에서 전체 시스템으로 작업할 수 있다.
1.7 Workspace
폴리리스 코드베이스에서 모든 빌딩 블록을 저장하고 프로젝트를 구성하는 곳
2 폴리리스가 해결하고자 하는 문제는?
- 단일 개발 프로젝트를 통해 코드탐색, 디버깅, 리팩토링, 단일 REPL 등 모노리스 코딩의 모든 이점을 누리면서도 컴포넌트를 어떤 조합의 아티팩트에도 배포할 수 있는 유연성을 유지할 수 있어 개발 환경이 만족스러움
- composable(구성가능), reusable(재사용), replaceable(교체가능)한 적절한 수준의 추상화를 갖춘 빌딩 블록을 제공하여 서비스 설계 간소화
- 컴포넌트는 본질적으로 단순하고 추론하기 쉬우며, 코드에 불과하고 인터페이스가 명확하며 구현이 숨겨져 있다.
- 컴포넌트는 전체 코드베이스에서 코드 중복이 전혀 없을 정도로 코드 재사용을 극대화
- 프로젝트는 모든 브릭 세트를 결합할 수 있도록 하며 배포 유연성을 극대화한다.