pkasarda/robust-architecture

견고한 아키텍처 (Robust Architecture)

설명과 검증이 가능한 가장 작은 설계를 산출하십시오. 규칙은 결정을 안내할 뿐, 정확성을 인증하지 않습니다. 유용한 아키텍처는 중요한 사실을 명시적으로 만들고, 규칙에 권위 있는 근거를 제공하며, 무언가 실패하거나 변경될 때도 이해 가능한 상태를 유지합니다.

결과(consequence)로부터 시작하라

기존 시스템의 경우, 다이어그램이나 이전 제안을 신뢰하기 전에 실제 엔트리포인트, 호출자, 상태 저장소 및 검사를 조사하십시오. 새로운 시스템의 경우, 요구사항과 가정을 구분하십시오. 컴포넌트를 선택하기 전에 첫 번째 실제 흐름을 설명하십시오.

결정을 바꾸는 제약 조건만 기록하십시오: 사용자와 권한, 운영 볼륨, 지연 시간 또는 리소스 예산, 가용성, 장애 조건, 복구 및 내구성 요구사항, 배포 제약 조건, 그리고 팀이 운영할 수 있는 것. 정확성에 영향을 미치는 제품 선택이 누락된 경우 이를 요청하십시오. 해당 선택이 해결되지 않은 상태에서 독립적이고 되돌릴 수 있는 작업은 계속 진행하십시오.

개입 수준을 조정하십시오:

• 모델/소유권 격차: 필요한 사실, 완전한 연산 또는 일관된 권한이 없거나 분할된 경우. 해당 계약을 독자가 패치하기 전에 해결하십시오.
• 경계 결함: 적절한 소유자는 존재하지만 호출자가 이를 우회하거나 집행이 불완전한 경우. 해당 소유자를 심화하거나 사용하십시오. 계층 간 결함이 자동으로 새로운 아키텍처를 요구하지는 않습니다.
• 제품 격차: 필요한 동작이 결정되지 않은 경우. 구체적인 결과와 가장 작은 선택지를 제시하고, 묵시적으로 선택하지 마십시오.
• 표현/로컬 결함: 올바른 기본 사실에 로컬 렌더링, 구문 분석 또는 복사 수정이 필요한 경우. 일반적인 로컬 수정을 적용하고 여기서 아키텍처 워크플로를 중단하십시오.

대용량 파일, 중복 구문, 누락된 패턴 이름 또는 제안된 패키지 자체는 모델 격차의 증거가 아닙니다.

보호된 리소스에 접근하는 설계 또는 검토의 경우, authorization 스킬이 설치되어 있으면 이를 적용하십시오. 이 스킬은 접근 정책 워크스루를 소유합니다. 이 스킬만 사용할 때는 아래의 로컬 소유권 및 신뢰 규칙을 유지하십시오.

사실과 규칙에 근거를 제공하라

사실 또는 불변 조건, 그 논리적 권한(authority), 그리고 이를 변경할 수 있는 연산의 이름을 지정하십시오. 권한은 로컬 함수, 파일 게시자, 라이브러리 핸들, 프로세스 또는 서비스가 될 수 있으며, 반드시 서버나 새로운 모듈일 필요는 없습니다.

• 모든 관련 생성자에 대해 규칙을 적용할 수 있는 지점에 규칙을 배치하십시오. 진입 어댑터는 호출자 신뢰를 확립하고, 입력을 구문 분석하고, 해당 소유자를 호출하고, 결과를 변환합니다. 유용한 초기 검사는 피드백을 개선하고, 권위 있는 검사는 실제 효과를 보호합니다.
• 공유 데이터를 소유하는 주체를 명시적으로 모델링하십시오. 누락된 부모 또는 범위 값이 자동으로 전역 권한이 되는 것은 아닙니다. 가시적인 제어뿐만 아니라 읽기, 직렬화 및 효과에 행위자의 실제 정책을 적용하십시오.
• 현재 관계, 불변 발생 사실 및 예측(projection)을 분리하십시오. 기능이 실제로 필요로 하는 이력이나 스냅샷을 저장하십시오. 현재 관계는 누락된 과거 사실을 재구성할 수 없습니다. 알 수 없는 레거시 이력은 정직하게 표시하십시오.
• 재시도에 연산 식별자를 부여하십시오. 두 개의 동일한 페이로드는 별개의 의도일 수 있습니다. 재시도 정확성이 중요할 때 현재 권한 하에 키 범위, 부적절한 재사용, 보존 및 재생을 정의하십시오.
• 소비자가 동의해야 하는 파생 규칙과 표현에 대해 하나의 유지 관리되는 정의를 제공하십시오. 대상 그룹, 코호트, 단위 및 시간 의미 간의 의도된 차이점을 보존하십시오. 공유가 인공적인 의존성을 만들 때는 저렴한 로컬 표현 중복을 유지하십시오.
• 명시적으로 지정된 다중 작성자 또는 오프라인 설계는 유효합니다. 단일 물리적 작성자를 항상 강제할 수 있다고 가정하지 말고 충돌 의미, 조정 및 파티션 동작을 명명하십시오.

경계는 결정을 숨기고 호출자로부터 지식을 제거함으로써 존재 가치를 얻습니다. 이를 직접 확인하십시오: 변경 후 어떤 호출자가 더 이상 규칙, 저장소 레이아웃 또는 순서를 알지 못합니까? 모든 호출자가 동일한 비즈니스 단계를 조정하도록 하는 래퍼는 소유권을 이동시키지 않았습니다.

완전한 결과를 소유하라

하나의 의도를 중요한 효과를 통해 추적하십시오. 함께 유지되어야 할 것, 권위 있는 완료 지점, 그리고 실행이 해당 지점 이전 또는 이후에 중단될 경우 사용자가 받는 것을 명시하십시오.

캐시 및 백그라운드 콜백을 포함한 모든 관찰 가능한 게시를 열거하십시오. 비동기 작업의 경우, 결과가 속한 연산, 식별자, 버전 및 수명을 식별하고 각 관련 게시 경계에서 적용 가능성을 확인하십시오. 늦은 뷰 검사는 이전 캐시 또는 저장소 쓰기를 보호할 수 없습니다. 소비자 취소와 이미 커밋된 비즈니스 효과 취소를 구분하십시오.

하나의 권한 내에서 불가분성이 필요한 불변 조건에는 실제 원자적 프리미티브를 사용하십시오. 동시 작성자가 이전 읽기를 무효화할 수 있는 경우, 효과 또는 동등한 직렬화에서 적용 가능한 범위, 상태 및 버전을 강제하십시오. 메커니즘을 도달 가능한 인터리빙에 맞추십시오; 단일 스레드 순수 변환에는 데이터베이스 스타일의 동시성 메커니즘이 필요하지 않습니다.

네트워크, 프로세스, 파일 또는 비동기 경계에서는 경계 검사를 읽으십시오. 관련 분기를 선택하십시오: 내구성 효과, 리소스 수명, 실시간 작업, 또는 상태/이력. 로컬 트랜잭션은 외부 효과를 원자적으로 만들지 않습니다. 알 수 없는 결과가 반드시 실패를 의미하지는 않습니다. 재시도를 추가하기 전에 복구 및 정직한 보류/부분 결과를 정의하십시오.

재사용 가능한 API의 경우, 입력, 출력, 거부, 소유권 및 정리 책임을 명시적으로 만드십시오. 의미 있는 오류/제어 흐름 구분을 보존하십시오. 보호된 데이터를 노출하지 않고 실패를 설명할 수 있는 곳에 진단을 배치하십시오. 로그는 복구 메커니즘이나 인증/이력 데이터베이스가 아닙니다.

비례하는 구조를 선택하라

기존의 응집력 있는 모듈과 지원되는 플랫폼 메커니즘을 선호하십시오. 새로운 소규모 애플리케이션에서는 잘 경계 지어진 함수나 모듈 몇 개로 충분할 수 있습니다. 독립적인 확장, 장애 격리, 런타임 제약 조건 또는 조직적 소유권이 필요한 구체적인 요구사항이 있을 때 별도 배포 또는 인프라 도입을 고려하십시오. 중요한 트레이드오프를 설명하면서 명시적으로 선택된 플랫폼을 존중하십시오.

가장 작은 변경을 그럴듯한 대안과 나란히 평가하십시오. 정확성, 리소스/운영 비용 및 되돌리기 가능성의 중요한 차이점을 설명하십시오. 각 설계 결정을 하나의 근거에 유지하십시오. 안정적이고 유용한 지점만 독립적으로 추출하십시오. 물리적 폴더, 패키지 및 서비스는 입증된 경계를 따르며, 입증 자체를 제공하지 않습니다.

배치 변경 전반에 걸쳐 전체 불변 조건을 보존하십시오. 마이그레이션 및 롤아웃은 기존 데이터, 이전/새 작성자, 공개 소비자 및 롤백 호환성을 고려해야 합니다. 컬럼, API 또는 리소스 제거는 해당 의무와 소비자가 종료되었음을 증명해야 합니다.

그것을 반증하려고 시도하라

논쟁 중인 경계를 실행하는 얇은 수직 슬라이스를 선택하십시오. 주장과 관련된 실제 저장소, 파일, 프로토콜 또는 리소스 지점을 사용하십시오. 진정한 외부 의존성만 분리하십시오. 구현이 없는 초기 설계의 경우, 식별 실험을 지정하고 결과를 알 수 없는 상태로 두십시오.

관련 실패로 불변 조건을 검증하십시오: 잘못된 권한, 오래된 상태, 반복 또는 재정렬된 작업, 완료 경계에서의 충돌, 취소, 누락/모호한 이력, 그리고 실제 부하 또는 타이밍 제한. 규칙을 구분할 때 명시적인 유인물과 통제된 인터리빙 또는 클록을 사용하십시오. 테스트는 해당 규칙이 제거될 때 실패해야 하며, 단순히 모의 호출 횟수를 세거나 선택된 이름을 인식해서는 안 됩니다.

안전성과 진행을 모두 확인하십시오: 유효한 연산이 어떻게 결국 완료되거나 정직한 거부를 제공하는지; 보류 중인 작업이 어떻게 복구되는지; 메모리, 큐, 연결 및 지연 시간이 어떻게 제한되는지. 이러한 검사는 모든 이론적 실패를 되풀이하기보다 운영 범위에서 선택하십시오.

작동한다고 주장할 때는 마운트된/사용자 또는 공개 라이브러리 흐름을 관찰하십시오. 단위 테스트, 다이어그램, 초록색 재시도, 벤치마크 추측 및 합성 픽스처는 자신의 테스트된 경계만 확립합니다. 측정된 결과, 소스 조사 결과, 가정, 누락된 결정 및 실행되지 않은 증명을 구분하십시오.

검토 가능한 결정을 전달하라

출력을 결정의 규모에 맞추십시오. 실질적인 설계의 경우 다음을 제공하십시오:

1. 구체적인 흐름, 제약 조건 및 중요한 미지수.
2. 불변 조건, 명명된 권한 및 영향을 받는 생성자/소비자.
3. 상태/이력, 신뢰, 완료 및 실패 경계 (성공 및 실패를 추적할 수 있는 계약 포함).
4. 선택된 작은 구조, 관련 대안, 그리고 트레이드오프가 적합한 이유.
5. 수용, 복구 및 진화/롤아웃 검사가 포함된 첫 번째 슬라이스.
6. 준비된 것, 제품 결정 또는 증명이 필요한 것, 그리고 실제로 검증된 것.

작은 다이어그램은 경계를 더 명확하게 할 때만 사용하십시오. 로컬 수정의 경우 빈 템플릿 섹션을 건너뛰십시오. 사용자의 범위를 보존하십시오: 설계/검토 요청은 결정을 산출하며, 구현, 마이그레이션, 배포, 게시 또는 라이브 데이터 변경에 대한 허가가 아닙니다.

이 스킬을 채택하거나 평가할 때는 평가 프로토콜을 참조하십시오. 주요 배경 지식은 기초에 나열되어 있습니다. 이는 추론에 정보를 제공하며 개별 설계를 검증하지 않습니다.