코드 생성 전 아키텍처 결정

프로젝트 유형

달리기 전 lino project new, 시스템의 목표를 정의합니다. 내부 관리 프로젝트, 다중 tenant SaaS, 공용 API 및 분산 플랫폼의 요구 사항은 서로 다릅니다.

• 간단한 적용: 컨텍스트가 적고 단일 배포가 가능하며 운영 독립성에 대한 필요성이 낮습니다.
• 모듈형 단일체: 명확한 경계와 낮은 운영 비용을 갖춘 동일한 프로세스의 여러 모듈.
• 마이크로서비스: 별도의 서비스, 독립적인 배포, 비동기식 통신 및 더 큰 운영 복잡성.
• SaaS: tenant 격리, 강력한 보안, secrets, rate limiting, observability 및 명확한 청구/운영 결정이 필요합니다.

이 결정은 또한 첫날에 어떤 우려 사항이 발생해야 하는지를 정의합니다. SaaS는 세입자를 늦은 세부 사항으로 처리할 수 없습니다. 공개 API는 rate limiting 및 명확한 계약 없이는 탄생할 수 없습니다. 이벤트가 있는 솔루션은 Outbox, 멱등성 및 observability을 고려해야 합니다. 여러 문화권을 사용하는 애플리케이션은 처음부터 문자열이 흩어지는 것을 방지해야 합니다.

기반을 만들 때 지원되는 문화권, 분산 캐시, 비동기 통신, 코드 분석기, 데이터베이스 유형, 웹 앱 존재, 인증, tenant 및 작업자 등 주요 선택 사항을 기록합니다. 이러한 옵션은 패키지, 템플릿, AppHost, 매개변수, secrets, 생성된 프로젝트 및 나중에 아키텍처를 변경하는 데 필요한 노력에 영향을 미칩니다.

모듈식 대 모듈식 Monolith 마이크로서비스

모듈식 모놀리스를 사용하면 명확한 내부 계약을 통해 도메인을 모듈로 구성하여 빌드, 디버그 및 배포를 더 간단하게 유지할 수 있습니다. 마이크로서비스는 독립적인 규모, 별도의 팀, 안정적인 비즈니스 경계 또는 다양한 운영 요구 사항 등 강력한 이유가 있는 경우에만 성과를 냅니다.

모듈식 모놀리스로 시작한다고 해서 아키텍처를 무시하는 것은 아닙니다. 이는 도메인이 검색되는 동안 간단한 배포를 유지하지만 모든 것이 단일 엔터티, 서비스 및 공유 테이블이 되는 것을 방지하는 내부 제한을 만드는 것을 의미합니다. 이것이 '단순하게 시작하는 것'과 '구조 없이 시작하는 것'의 차이입니다.

Lino는 두 경로를 모두 지원합니다. 결정은 기술적 선호뿐만 아니라 팀의 영역과 운영 역량을 따라야 합니다. 마이크로서비스에는 배포 자동화, 분산 observability, 계약 버전 관리, 네트워크 내결함성, 메시징, 재처리 및 데이터 거버넌스가 필요합니다. 팀이 아직 이를 안전하게 운영할 수 없다면 너무 빨리 배포하면 위험이 커지는 경우가 많습니다.

도메인을 학습하고, 제품을 검증하고, 작업을 제어 가능한 상태로 유지하는 것이 우선순위인 경우 모듈식 모놀리스를 사용하십시오. 별도의 규모, 실제 소유권이 있는 팀, 독립적인 릴리스 주기 또는 시스템 부분 간 호환되지 않는 인프라 요구 사항 등 운영 독립성이 이미 구체적인 요구 사항인 경우 마이크로서비스를 사용합니다.

서비스 및 모듈 제한

좋은 제한은 결합을 줄이고 누가 각 규칙을 소유하는지 명확하게 만듭니다. 테이블별 또는 화면별 서비스 생성을 피하세요. 서비스와 모듈은 비즈니스 기능을 나타내야 합니다.

• Catalog: 제품, 카테고리, 상업 정보 및 판매 상담 데이터.
• Sales: 주문, 장바구니, 적용된 가격, 스냅샷 및 상업 흐름.
• Stock: 가용성, 예약 및 이동.
• Security: 사용자, 역할, 권한, 인증 및 토큰.

좋은 제한에는 고유한 언어, 함께 변경되는 규칙, 명확한 소유권이 있는 데이터 및 다른 컨텍스트와 통신하기 위한 명시적인 계약이 있습니다. 잘못된 제한은 일반적으로 "공통" 모듈, 여러 영역에서 공유되는 엔터티, 모든 사람이 참조하는 테이블 또는 새 화면이 있다는 이유만으로 생성된 서비스로 나타납니다.

모듈에 다른 모듈의 데이터가 필요한 경우 API, 통합 이벤트, 섀도우 엔터티 또는 경계 재형성 중에서 선택하세요. 다른 모듈의 뱅크에 직접 접근하는 것은 구조적 결합의 표시입니다. 두 모듈이 동일한 프로세스에서 실행되고 동일한 물리적 데이터베이스를 사용하는 경우에도 스키마, 지속성 프로젝트 및 계약은 비즈니스 경계를 ​​보호해야 합니다.

• 좋은 제한 기호: 모듈은 내부 세부 사항으로 인해 다른 모듈을 강제로 다시 컴파일하지 않고도 엔터티와 마이그레이션을 발전시킬 수 있습니다.
• 약한 임계값 신호: 엔터티를 간단히 변경하려면 해당 엔터티를 알아야 하는 화면, 쿼리 및 모듈 핸들러를 검토해야 합니다.
• 숨겨진 종속성 기호: 소비자는 테이블, 기술 분야 또는 생산자의 내부 규칙에 대해 "너무 많이 알아야" 합니다.

의식적인 기술 부채

기술 부채는 단순한 불완전성이 아닙니다. 미래의 비용을 알면서 품질을 미루는 결정이다. 문제는 이름도 없고, 소유자도 없고, 지불 계획도 없는 부채가 발생한다는 것입니다.

SaaS 또는 모듈형 시스템에서 가장 위험한 기술 부채는 단순한 방법이 아닙니다. 개별적으로 변경할 수 없는 모듈, 안정적인 격리가 없는 tenant 데이터, 저장소 내의 secrets, 제한이 없는 민감한 엔드포인트, 재처리가 없는 이벤트 또는 명확한 계약이 없는 통합 등 진화를 제한하는 것은 부채입니다.

• 생성 및 사용자 정의 중에 사용되는 문서 바로가기입니다.
• 다음 세대 단계로 이동하기 전에 빌드 및 테스트를 실행하세요.
• 반복적인 로컬 해킹으로 인해 발생한 문제를 해결하지 마세요. 패턴이 잘못된 경우 패턴이나 템플릿을 조정하세요.

모든 아키텍처 결정을 감사 가능한 것으로 간주합니다. 메시징을 활성화하지 않기로 선택한 경우 현재 흐름은 비동기 처리에 의존하지 않는다는 점에 유의하세요. tenant당 열을 선택하는 경우 필터와 테스트를 확인하세요. 동기식 통합을 선택하는 경우 시간 초과, 사용 불가 및 계약 오류를 설계의 일부로 가정합니다.

커뮤니케이션 전략

일관성, 대기 시간, 추적성 및 결합에 대한 실제 요구 사항에 따라 통신을 선택하십시오. 주요 질문은 “어떤 기술을 사용할 것인가?”가 아니라 “생산자는 지금 대답이 필요합니다. 소비자가 작업을 취소하지 못하면 데이터의 소유자는 누구입니까?”입니다.

모듈식 시스템에서 가장 일반적인 오류는 통신을 숨겨진 종속성으로 변환하는 것입니다. 한 모듈이 다른 모듈의 테이블을 쿼리하고, 내부 엔터티를 재사용하고, 외부 저장소를 삽입하거나, 실패를 처리하지 않고 동기 호출을 생성합니다. 이는 처음에는 생산적인 것처럼 보이지만 경계가 더 이상 명확하지 않기 때문에 후속 변경이 더 위험해집니다.

• 동기 호출: 즉각적인 상담과 수용 가능한 의존성에 좋습니다. 긴 폭포에서는 피하십시오.
• 도메인 이벤트: 동일한 적용 한도 내에서 내부 반응.
• 통합 이벤트: 일반적으로 Outbox를 사용하여 모듈, 서비스 또는 시스템 간의 통신.
• 그림자 엔터티: 생산자에게 직접 의존하지 않고 상담 및 검증을 위한 최소한의 로컬 사본입니다.
• 외부 HTTP 통합: 시간 초과, 재시도, 로그 및 오류 처리 기능을 갖춘 타사 서비스에 적합합니다.

규칙에 즉시 업데이트가 필요한 경우 동기 스트리밍을 사용하거나 임계값을 수정하세요. 최종 일관성을 허용하는 경우 결합을 줄이기 위해 이벤트를 선호합니다. 소비자가 다른 컨텍스트에서 데이터의 작은 하위 집합만 읽어야 하는 경우 전체 원본 엔터티를 노출하는 것보다 섀도우 엔터티가 더 안전할 수 있습니다.