여기에 업데이트 일정에 대해 알아보십시오.

구성 가능한 솔루션은 빠르고 안정적으로 조정됩니다. 구성 가능하도록 설계된 시스템은 서로 원활하게 작동할 수 있는 의미 있는 단위 또는 빌딩 블록으로 구축되며, 서비스 내부 및 외부에서 쉽게 교체할 수 있습니다. 시스템에 구성 기능을 구축하면 시스템의 개별 단위를 재구성하거나 재구성하여 새로운 기능을 도입하거나 기술 부채를 제거할 수 있습니다. 구성 가능성은 팀이 소량의 변경을 통해 의미 있는 기능을 구축하고 제공하는 데 집중할 수 있으므로 더 빠르고 예측 가능한 배달 주기와 릴리스를 제공합니다.

컴포지블 시스템을 사용하면 비즈니스에서 내부적인 자극이든 외부 요인으로 인한 자극이든 더욱 안정적으로 빠르게 적응할 수 있습니다. 복합성은 시스템의 복원성을 높이고, 솔루션과 아키텍처 패턴을 더욱 의도적인 방식으로 만드는 데 도움이 됩니다.

우려 사항 분리, 상호 운용성, 패키지 가능성의 세 가지 핵심 습관을 구축하여 Salesforce 솔루션의 구성 가능성을 높일 수 있습니다. 아래에서 구성 가능한 시스템의 단일 단위 또는 구성 가능한 시스템의 여러 단위에 대한 두 가지 방법으로 이러한 습관의 관계를 확인할 수 있습니다.

단일, 컴포지블 유닛:

구성 가능한 시스템:

소프트웨어 엔지니어링 및 시스템 아키텍처의 기본 개념인 걱정 분리은 모듈식 단위로 분리할 수 있는 더 큰 시스템 내에서 다양한 관심사를 식별해야 합니다. 시스템 내에서 우려 사항을 강력하게 분리하려면 시스템 전체에서 응용 프로그램 논리 및 기능에 대한 의미 있는 단위를 만들어야 합니다. 소규모 단위를 사용하면 앱 배달 및 서비스 점검 팀이 더 큰 시스템의 중단을 최소화하면서 변경 방법과 위치를 쉽게 이해할 수 있습니다. 소규모 유닛은 또한 기술 부채를 해결할 때 작업을 집중하는 방법과 위치를 명확하게 설명하고 시스템의 전체적인 읽기 기능에 기여합니다.

비즈니스 역량 및 상태 관리를 지향하여 Salesforce 조직에서 우려 사항을 더 잘 구분할 수 있습니다.

Salesforce 시스템의 경우 문제 분리에 가장 적합한 접근 방식은 비즈니스 지향적 관점을 적용하여 시스템 내의 모듈 단위 또는 기능을 식별하고 구성합니다. 이는 엔지니어링 중심 보기와 달리 기술적 기능을 기반으로 단위를 식별합니다. 우려 사항을 구분하는 비즈니스 지향 관점에서는 비즈니스 및 비즈니스 사용자에게 제공하는 서비스를 기반으로 시스템에서 코드 및 사용자 정의를 구성해야 합니다. 이 접근 방식을 취하는 것은 시스템의 중복 또는 중복 기술 기능에 대한 잠재력을 무시하는 것을 의미하지는 않습니다. 대신 기술 서비스가 비즈니스에 대해 투명한 구성 원칙에 명확하게 매핑됨을 의미합니다.

비즈니스 역량을 기반으로 비즈니스 분석 및 검색 팀 간의 전달이 가능한 한 간단하게 처리되도록 지원합니다. 앱 빌더가 구성 가능한 아키텍처에 작업 단위가 매핑되는 위치를 모르는 경우 구성 가능한 앱 환경이 아닌 혼란스러운 상황이 있습니다. 비즈니스에서 요구하는 종료 상태와 조직 내의 모듈 단위 간의 매핑이 명확하지 않으면 개발 팀 또는 공급업체가 시스템에 중복 기능을 구축할 가능성이 높아집니다.

기능 단위를 비즈니스 역량에 맞추려면 다음을 고려하십시오.

• 할 일을 시작하십시오. 사용자 및 비즈니스 자체의 수행할 작업(JTBD)에 초점을 맞춥니다. Tony Ulwick가 선도한 JTBD 접근 방식은 사람들이 제품 또는 서비스를 사용하여 달성하려는 "작업" 또는 실제 목적을 이해하는 데 중점을 두고 있습니다. 이는 사용자의 역할 관련 과업 또는 비즈니스 프로세스의 개별 단계보다 더 높은 수준의 추상화입니다. 예를 들어 중복 확인 및 주소 확인과 같은 과업은 "고객 단일 보기 설정"이라는 상위 순서의 함수에 속할 수 있습니다. 이러한 상위 비즈니스 기능을 명확하게 이해하면 시스템의 일부를 해당 기능에 매핑할 수 있습니다.
• 보고 구조가 아닌 능력 지향 사업부의 내부 계층은 수행할 의미 있는 기능 또는 작업을 프록시하는 것이 아닙니다. 비즈니스의 내부 계층은 프로세스 및 팀 구조(예산 제외)에 중대한 영향을 미칩니다. 이는 중요한 물류 고려 사항입니다. 그러나 비즈니스의 기능적 요구 사항은 물류보다 더 높은 추상 수준에서 작동합니다. 상위 기능 대신 보고 구조를 제공하는 모듈을 만드는 경우 해당 모듈이 비즈니스 기능과 연결되는 방식을 식별하기 위해 추가 단계를 수행해야 할 수 있다는 점에 유의하십시오.
• 반복적이세요. 먼저 비즈니스와 파트너 관계를 맺어 최소 수명 가능한 제품(MVP)에 적합한 기능을 식별합니다. 기능을 식별하면 해당 MVP 구축을 시작합니다. 구축할 때 생성하는 기능 유닛의 중심에 있는 프로세스, 메타데이터, 이벤트 또는 메시지를 식별합니다. 외부 종속성인 프로세스, 메타데이터, 이벤트 또는 메시지를 식별합니다. 더 많은 기능 유닛이 설계되면 API 관리 및 종속성 관리을 구현하여 서로 잘 작동하는 유닛을 구축합니다(실로 유닛을 구축하는 대신).

아래의 패턴 및 안티패턴 목록은 Salesforce 솔루션 내에서 비즈니스 기능에 대한 올바른(그리고 나쁜) 지향성을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다.

Salesforce에서 비즈니스 기능을 효과적으로 활용할 수 있는 도구에 대해 자세히 알아보려면 컴포지블과 관련된 도구를 참조하십시오.

시/도 관리는 다양한 시점에서 시스템 전반에서 정보를 이동하는 데 중점을 둡니다. 효과적인 상태 관리를 통해 응용 프로그램이 계획되지 않은 결과 또는 불확실한 결과를 최소화하면서 복잡한 데이터 플로 또는 상호 작용을 처리할 수 있습니다. 모듈식 Salesforce 조직에서 상태를 관리하면 단위 내 및 간에 논리 플로에 대한 명확한 경로와 계획되지 않은 실행 동작에 대한 우수한 경로를 구축할 수 있습니다. 시/도 관리를 사용하면 모듈식 Salesforce 응용 프로그램 단위에서 일관된 논리 스트림을 만들 수 있습니다. 대부분의 경우 유닛 간의 정보 흐름을 구성하기 위해서는 상호 운용성이 필요합니다.

결합된 단위 전반에서 상태를 관리하는 데 어려움을 겪는 경우 Salesforce에서 단독 응용 프로그램 개발이 발생하는 경우가 많습니다. 이는 단수 플로 내에서 복잡한 프로세스를 오케스트레이션하려는 시도로 구축된 대규모 "모노플로"에서 볼 수 있습니다. 또 다른 예는 스파게티 코드를 통해 복잡한 프로세스를 오케스트레이션하는 대규모 Apex 클래스 또는 긴 일련의 단일 사용 방법입니다. 이러한 유형의 응용 프로그램 아키텍처는 리팩터링 및 디버깅을 어렵게 만들고 새 팀 구성원 또는 공급업체의 온보딩 시간을 늘립니다. 또한 기능을 재사용할 수 없으므로 비즈니스에 전달되는 응용 프로그램의 가치를 줄일 수 있습니다.

모듈식 Salesforce 조직에서 상태를 관리하려면 다음을 고려하십시오.

• 시/도 및 시/도 없는 패턴을 사용하는 시기를 결정합니다. 시/도 패턴은 실행 경로 전반에 걸쳐 정보를 보존하며, 시/도 없는 패턴은 보존하지 않습니다. 분리된 시스템에서 상태가 없는 패턴을 사용하면 구성 요소가 더 빠르게 재구성되고 부작용이 줄어듭니다. 그러나 상태가 없는 패턴은 모든 사용 사례에 적합하지 않습니다. 데이터 작업을 위한 구성 요소를 구축하는 경우 상태 지정 패턴이 시스템 전체의 데이터 무결성 및 일관성에 도움이 됩니다. 구성 요소가 다음 기준을 충족하는 경우 상태가 있는 패턴을 사용합니다.
  • 더 큰 실행 경로 내의 배치 인식은 구성 요소의 동작에 필수적입니다.
  • 다운스트림 작업의 결과를 기반으로 구성 요소의 동작을 변경해야 합니다(예: 다운스트림 구성 요소의 롤백/오류/성공 메시지를 기반으로 실행을 변경해야 함).
  • 구성 요소가 작업을 완료하기 위해 외부 또는 다운스트림 시스템의 응답을 기다려야 합니다.
• 주 정보에 대한 의미 있는 범주 생성 시/도는 Salesforce 조직 내부(또는 그 외부)의 깊고 광범위한 정보에 적용할 수 있는 모호한 용어로서, 용어 자체가 거의 의미가 없습니다. 따라서 상태형 패턴을 구축하는 데 필요한 첫 번째 단계는 시스템 내에서 가장 중요한 상태형 실행 경로(또는 상태형 행동의 종류)에 대한 의미한 범주를 만드는 것입니다. 고려해야 할 몇 가지 범주:
  • 탐색 및 양식
  • 데이터베이스 작업
  • 배치 및 대량 작업
  • 오류
• ** 데이터베이스 트랜잭션 측면에서 데이터 관련 상태를 정의합니다**. 플랫폼의 내장형 동작은 Salesforce에서 데이터에 대한 대부분의 시/도 고려 사항을 제한합니다. 이 동작에 대해 또는 이 동작에 대해 관리하지 마십시오. 설계하고 사용합니다. 배포된 트랜잭션 논리를 최소화하거나 제거하는 솔루션을 설계합니다. (자세한 내용은 데이터 처리을 참조하십시오.)
• 기능 단위 내부 및 전체에서 발생하는 상태를 지정합니다. 기능 단위를 더 큰 시스템에 어셈블할 때 상태가 없는 구성 요소와 상태 구성 요소 동작을 혼합하는 경우에 유의하고, 처리에 끝없는 루프나 공백을 일으킬 수 있는 조합을 방지합니다.
• 수수료 정의 구성 요소가 상태 관련 데이터를 시스템의 다른 부분으로 전송하는 데 사용할 메시지 또는 이벤트 패턴을 고려하십시오. 거래 인식 및 구성 요소의 처리를 구축하고 있는지 확인합니다. 핸드오프에 배포된 트랜잭션 논리를 포함하지 마십시오.
• 프로세스 다이어그램과 상태 간의 매핑 만들기 프로세스 다이어그램은 다양한 시점에서 시스템을 통해 정보를 이동하는 단계를 자세히 설명합니다. 상태 다이어그램에 정보(상태)의 실제 변경 사항이 표시됩니다. Salesforce 다이어그램 형식의 메타데이터 바닥글 부분을 사용하여 프로세스의 각 단계 내에서 변경되는 정보 상태를 캡처합니다. 프로세스 다이어그램과 상태 다이어그램을 구분하는 경우 해당 다이어그램을 연결해야 합니다. 이 개념은 시스템을 통해 이동하는 정보가 아닌 설계 및 구현 시 프로세스 또는 시스템 환경의 현재 및 향후 상태를 수집하는 것과 혼동해서는 안 됩니다.

아래의 패턴 및 안티패턴 목록은 Salesforce 솔루션 내에서 올바르고 나쁜 상태 관리를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별할 수 있습니다.

상태 관리용 Salesforce 도구에 대한 자세한 내용은 Composable과 관련된 도구를 참조하십시오.

다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 관심 분리를 위한 더 많은 패턴을 알아보십시오.

상호 운용성을 위해 설계된 시스템에서는 구성 요소가 정보를 교환하고 함께 효율적으로 작업할 수 있습니다. 상호 운용성은 모듈식 시스템을 사일로 시스템이 아닌 구성 가능한 시스템으로 만들기 위한 핵심입니다. 상호 운용성은 연결하게 연결된 시스템에서 달성하기 어려울 수 있습니다. 시스템 전체에서 단위 간의 독립성과 전체적인 관심 분리을 저해하지 않는 일관된 통합 방법에 대한 표준을 설정해야 합니다.

상호 운용성은 사용자 환경의 품질에도 영향을 미칩니다. 사용자는 하나의 영역(예: 주문 정보)에서 생성된 데이터를 다른 영역(예: 마케팅 캠페인)에서 사용할 수 있을 것으로 예상하며, 빌더는 플로 구축 또는 API 인증과 같은 작업 방법을 배우면 다음 문제를 해결할 때 익숙한 기법이 작동하는지 확인할 수 있습니다. 상호 운용성을 위해 설계하지 못하면 예비 아키텍처, 데이터 복제, 프로세스 비효율성, 개발 및 지원 비용이 증가합니다.

메시징 및 이벤트 매김 및 API 관리와 함께 모듈식 시스템에서 상호 운용성을 만들 수 있습니다.

메시지 및 이벤트는 시스템 전반의 구성 요소를 활성화하여 정보를 보내고 받을 수 있는 두 가지 방법입니다. 전달할 수 있는 콘텐츠 측면에서 이벤트와 메시지는 유사합니다. 가장 큰 차이점은 보낸 사람의 동작입니다. 메시지를 보내는 구성 요소는 일반적으로 특정 대상에 데이터를 보내고 수신자의 반응을 기다립니다. 반대로, 구성 요소는 무언가가 발생했을 때 이벤트를 방출합니다. 특정 대상이나 응답에 대한 기대가 없습니다. 동작의 차이점은 다양한 커뮤니케이션 패턴을 지원합니다. 메시지는 시/도 커뮤니케이션 패턴을 지원하며, 이벤트는 시/도 없는 커뮤니케이션 패턴을 지원합니다. (이 차별에 대한 자세한 내용은 국가 관리를 참조하십시오.)

프로토콜에 맞춰 팀을 조율하고 Messaging 및 이벤트에 사례를 사용하는 것이 중요합니다. 표준이 명확하지 않으면 시스템 전체에서 패턴이 혼합될 수 있으므로 다음이 발생할 수 있습니다.

• 특정 사용 사례에 잘못된 패턴이 적용되는 성능 및 확장성 문제
• 최종 사용자에게 시스템이 불안정해 보이도록 하는 불일치 처리
• 오래 걸리는 문제 해결 시간 및 더 복잡한 서비스 점검 프로세스

메시지 및 이벤트를 설계하여 Salesforce 조직 내에서 더 느슨하게 연결된 구조를 만들 때 다음 사항을 고려하십시오.

• 동기화 및 비동기 사용 사례를 식별합니다. 이벤트를 사용하면 시스템 전체에서 누락된 통신, 상태가 없는 통신, 비동기식 통신을 수행할 수 있습니다. Messaging을 사용하면 더욱 긴밀하게 제어되고 상태를 유지하며 동기식으로 통신할 수 있습니다. 메시지 또는 이벤트를 사용할 시기를 결정할 때 커뮤니케이션이 동기식(잠재적으로 차단 가능)이거나 비동기식 및 차단되지 않아야 하는지 결정해야 합니다.
• 데이터 구조를 신중하게 정의하십시오. 구성 요소가 서로 전달하는 정보의 구조는 자유롭게 연결된 시스템을 관리하고 일관되게 유지하는 데 중요한 부분입니다. (이에 대한 자세한 내용은 API 관리를 참조하십시오.) 메시지 또는 이벤트를 설계할 때 중요한 고려 사항은 정보 구조를 변경해야 하는 빈도입니다. 시스템에 메시지 또는 이벤트 구조가 정의되고 구현되면 특히 이벤트 또는 메시지를 이미 외부 시스템에 정보를 보내는 데 사용 중인 경우 업데이트를 처리하기가 어려울 수 있습니다.
• 맞은 크기의 메시지 일반적으로 메시지 크기를 작게 유지하는 것이 가장 좋습니다. 그러나 메시지 크기와 메시지 볼륨 사이에도 균형을 맞춥니다. 시스템에서 더 작은 양의 데이터를 더 빠르게 처리할 수 있습니다. 처리 작업에는 수신자가 수신한 정보를 압축 해제하고 해석하고 수행할 작업을 결정해야 하므로 추가적인 비용이 포함됩니다. 이러한 단계는 완료하는 데 상당한 시간이 걸릴 수 있지만 대규모로 시스템을 구축하고 부담을 야기할 수 있습니다. 작업을 완료하기 위해 시스템의 구성 요소가 많은 작은 메시지를 연속으로 처리해야 하는 설계를 피하십시오. 메시지 크기를 올바르게 조정하려면 모든 다운스트림 구성 요소가 수많은 후속 메시지를 요청하거나 처리할 수 있다고 가정하지 않아도 전송된 정보를 성공적으로 처리하고 조치를 취해야 하는 최소 데이터 다운스트림 구성 요소를 설계할 수 있습니다.
• 확장성을 위한 설계 완전히 결합된 구성 요소를 사용하면 보다 쉽게 아키텍처를 확장할 수 있습니다. 교차 구성 요소 종속성을 제거하면 팀이 개별 구성 요소의 성능 또는 확장성을 개선하고 다른 구성 요소에 미치는 영향을 최소화할 수 있습니다. 그러나 느슨하게 연결된 구성 요소는 아키텍처의 규모에 상당한 복잡성을 부여합니다(특히 상태 관리의 경우). 유효한 사용자 환경 또는 데이터 무결성 이유로 더욱 긴밀하게 연결된 논리 또는 종속성이 필요한 프로세스를 식별하고 해당 프로세스에 비동기식/이벤트 기반 패턴을 도입하지 마십시오. 대신 동기화/메시지 기반 패턴 및 올바른 오류 처리를 사용하십시오.

아래의 패턴 및 안티 패턴 목록은 Salesforce 솔루션 내에서 올바른(그리고 나쁜) 메시지 및 이벤트가 어떻게 보이는지 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별할 수 있습니다.

Salesforce 메시징 및 이벤트 설정 도구에 대해 자세히 알아보려면 Composable과 관련된 도구를 참조하십시오. 주어진 사용 사례에 대한 이벤트 패턴 또는 도구를 선택하는 방법에 대한 자세한 내용은 Salesforce를 사용하는 이벤트 중심 아키텍처의 아키텍처 가이드를 참조하십시오.

Salesforce 솔루션 내에서 적절한 응용 프로그램 프로그래밍 인터페이스(API) 관리를 구축하면 시스템의 개별 구성 요소가 예측 가능한 커뮤니케이션 패턴을 따를 수 있습니다. Salesforce는 Salesforce 외부 시스템과 통신하는 데 사용할 내장된 보안 API를 제공합니다. (Salesforce Platform API에 대한 자세한 내용은 아키텍처 기본 사항을 참조하십시오.)

Salesforce 솔루션 내에서 효과적인 API 관리를 통해 구성 가능한 아키텍처를 구축할 수 있습니다. 이를 통해 Salesforce 조직 내 구성 요소가 효율적으로 정보를 전송하고 받을 수 있습니다. 또한 솔루션 빌더가 구축한 구성 요소가 시스템의 다른 구성 요소와 통신하는 방법에 대한 명확한 프로토콜을 따를 수 있으며, 조기에 불량한 구현을 식별할 수 있습니다. 또한 솔루션 빌더가 구축하거나 리팩터링 중인 특정 구성 요소에 집중할 수 있어 생산성과 품질이 향상됩니다.

엔터프라이즈 수준의 API 관리는 별도의 주제이며 포괄적인 API 관리 도구를 사용하면 가장 효과적입니다. (이 주제에 대한 MuleSoft 관점에 대한 자세한 내용은 API 관리란 무엇입니까?를 참조하십시오.)

Salesforce 솔루션 내에서 API 관리 기능을 구축하려면 다음을 고려하십시오.

• API를 예측 가능한 패턴 또는 커뮤니케이션 계약으로 생각하십시오. 입력 또는 출력 변수의 데이터 유형, 변수 이름, 지정된 패턴에 표시되어야(또는 표시하지 않아야 함)하는 정보의 일부 - 이들은 효과적인 API 관리를 위한 키입니다. 해당 정의는 설계 표준에 표시되어야 하며, 팀은 문서를 통해 해당 정의가 시스템의 특정 부분에 구현된 방식을 확인할 수 있어야 합니다. 새 개발에서 통합 환경으로 변경 사항을 병합하는 어려움을 확인하는 한 가지 방법은 API 커뮤니케이션을 잘못 구현했거나 어떠한 API 정의도 없었는지 확인하는 것입니다.

• API에 대한 생각을 코딩 전용으로 제한하지 마십시오. 이 컨텍스트에서 API를 정의하는 요소는 해당 메시지 내의 메시지 구조 및 변수의 일관성입니다. 일관성을 유지하는 한, API는 모듈식 자동 실행(또는 플랫폼 이벤트 트리거형) 플로 또는 플로 템플릿과 같은 선언적 사용자 정의뿐만 아니라 코드에서 구현할 수 있습니다. API 구현이 아니라 패키지화 가능성 및 테스트 가능성에 따라 코드 대신 플로에서 정의할 사항을 결정합니다.

• 수명 주기와 버전을 간단하게 유지하십시오. 응용 프로그램 개발의 모든 부분과 마찬가지로 API에는 수명 주기인 정의, 구축, 테스트, 배포, 유지 관리(사용 중지 포함)가 있습니다. Salesforce Platform API는 플랫폼의 빠른 릴리스 주기 때문에 달력 연도 내에 여러 버전을 릴리스합니다. (Salesforce 아키텍처 기본 사항에서 이 동작에 대해 자세히 알아볼 수 있습니다.) 따라서 Salesforce 고객이 특정 API의 여러 버전을 유지 관리하고 사용할 수 있어 플랫폼 API의 수명 주기가 상당히 복잡합니다. 이 수준의 복잡성은 PaaS 사용 사례에 적합하지만 플랫폼 내 솔루션 아키텍처에 불필요한 복잡성일 가능성이 높습니다(다음 참조: 읽기 안티 패턴). API에 대한 명확한 목적(예: 오류 처리)과 명확한 기준선 정의를 정의하는 데 중점을 두십시오. 각 API의 버전을 하나만 보유하도록 합니다.

• API를 검색 가능, 액세스 가능, 관리 가능으로 만들기 잠재 고객이 사용 가능한 API를 쉽게 찾을 수 있도록 API를 문서화하십시오. API는 기능 조화의 일환으로 원활하게 작동해야 합니다.

• 반복적이세요. 한 번에 하나의 내부 API만 정의하고 구현하는 데 중점을 두십시오. 이를 통해 API 정의를 빠르게 반복하고 지원되는 버전에 적합한 양식을 찾고 구현 경험에서 모범 사례를 수립할 수 있습니다.__

아래의 패턴 및 안티패턴 목록은 Salesforce 솔루션 내에서 올바르고 나쁜 API 관리를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다.

더 많은 정보는 더 많은 상호 운용성을 구축할 수 있도록 Salesforce에서 사용할 수 있는 도구에 대해 알아보려면 Composable과 관련된 도구를 참조하십시오.

다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 상호 운용성을 위한 더 많은 패턴을 알아보십시오.

Salesforce 조직에서 패키지 가능성을 만들면 조직의 기능은 패키지로 독립적으로 신뢰할 수 있게 개발하고 배포할 수 있는 유닛에서 가져옵니다. 이상적으로 이러한 유닛은 2세대 패키지의 유형으로 정의됩니다(잠금 해제 패키지 또는 ISV용 관리 패키지). 참고: 잘 설계된 솔루션은 해당 패키지 유형을 독점적으로 사용하므로 1세대 관리 패키지는 여기에 포함되지 않습니다.

Salesforce 조직에서 걱정 구분을 정의하고 기능 단위를 만드는 것은 한 가지입니다. 이러한 유닛을 패키지 아티팩트로 버전이 지정되도록 종속성을 명확하게 해제하고 관리하는 것이 좋습니다. 안정성과 메타데이터 격리 수준을 달성하려면 상당한 수준의 DevOps 및 아키텍처 성숙도가 필요합니다. 또한 개발 시간을 가속화하고 앱 빌더 환경을 개선하며 릴리스 및 릴리스 관리에 예측 가능성과 제어 기능을 제공합니다. 일부 조직에서는 효과적인 패키지를 정의, 유지 관리, 개발하는 데 필요한 인프라를 지원할 수 없습니다. 그러나 거의 모든 Salesforce 조직의 최종 목표는 패키지화 가능성을 달성해야 합니다.

확산된 커플링 및 종속성 관리에 집중하여 Salesforce 솔루션에서 패키징 가능성을 구축할 수 있습니다.

결합이 해제된 시스템에서는 개별 부품이 서로 강하게 연결되지 않습니다. 구성 가능한 시스템의 많은 장점은 느슨한 커플링으로 인해 발생합니다. 패키지 가능한 시스템에서 패키지(및 설치 조직) 간에 느슨한 커플링을 구현하면 패키지에 대해 작업하는 팀에 대해 명확하게 정의된 패키지와 생산적인 개발 주기를 확보할 수 있습니다.

Salesforce Platform에서 특정 조직에 밀도로 연결된 패키지를 구축할 수 있습니다. 이 기능은 기능 단위 정의와 패키징 성숙도 진행에 따라 조직에서 적절한 문제 분리 실험에 유용합니다. 그러나 이 접근 방식을 선택하면 소스 중심 개발, 버전 관리 사용 기능, 아티팩트 안정성 등 진정한 패키지 가능 메타데이터의 이점이 거의 실현되지 않습니다. 대신 다음과 같은 긴밀하게 연결된 시스템의 단점을 계속해서 경험할 수 있습니다.

• 중단 및 성능 문제를 야기하는 단일 지점 오류
• 예측할 수 없는 느린 배포
• 복잡하고 어려운 디버깅 및 문제 해결 주기
• 규모 및 성능 관련 문제

패키지 가능한 Salesforce 시스템의 최종 목표는 패키지에 흩어져 있는 패키지입니다.

Salesforce 메타데이터를 효과적인 패키지로 분리할 때 다음 사항을 고려하십시오.

• 사용자 정의는 데이터 대 메타데이터입니다. 패키지화 가능성과 관련하여 Salesforce Platform은 데이터와 메타데이터를 매우 다르게 처리합니다. 조직에서 어떤 기능이 메타데이터 또는 데이터인지 이해하는 것이 중요합니다. 패키지된 단위에는 데이터를 포함할 수 없습니다. 패키지된 단위로 기능을 추출하기 시작할 위치를 결정할 때 팀은 데이터로 저장된 사용자 정의를 패키지에서 모두 제외해야 하는지 또는 메타데이터 기반 구현으로 재구성해야 하는지 결정해야 합니다.
• 패키징이 팀에 미치는 영향 Salesforce 패키징의 물류 현실은 패키지 버전을 생성하고 릴리스하는 작업의 대부분이 Salesforce CLI 및/또는 CI/CD 기술을 숙지해야 한다는 것입니다. 즉, 하위 코드 및 프로그래밍 방식의 사용자 정의는 패키지 관련 DevOps 기술을 사용하여 작업할 수 있는 사람의 시간과 주의가 필요합니다. 팀이 기능 전달을 관리하는 방법에 따라 패키지 채택이 조직 전반의 여러 팀에 상당한 지연 또는 차단을 야기할 수 있습니다. 팀이 패키징을 통해 기능 전달을 관리할 수 있는지 확인하고 기술 또는 인력 부족을 해결할 계획을 수립해야 합니다. 솔루션에는 페어링된 프로그래밍 채택 또는 개발 환경용 CI/CD 작업 구현이 포함될 수 있습니다.
• 패키징이 환경 전략을 어떻게 바꿀 것인가. 패키지 기반 개발 수명 주기에서는 초기 작업을 스크래치 조직에서 수행해야 합니다. 해당 임시 소스 중심 개발 환경을 사용하면 더 빠르고 반복적인 주기를 수행할 수 있습니다. 또한 개발 팀에 대한 보다 세분화된 환경 액세스 제어와 프로덕션과의 더 큰 격리도 지원합니다. 패키지에 Sandbox 또는 프로덕션 환경에만 존재하는 비패키지 메타데이터 또는 데이터에 대한 종속성이 많을수록 팀이 스크래치 조직을 실제로 사용할 가능성이 떨어집니다. 비스크래치 조직 환경에서 소스 기반 개발 패턴을 허용하기 위해 Sandbox에서 소스 추적을 활성화할 수 있지만, 개발 팀은 스크래치 조직의 속도와 반복 속도를 활용할 수 없습니다.
• 패키지 버전이 릴리스와 관련된 방법 개발 패키지 버전을 지정해야 하는 빈도 및 단계를 계획합니다. 패키지 버전 요청은 24시간 순차적으로 조직당 제한됩니다. 일반적인 모범 사례로 패키지 내용을 변경할 필요가 없는 경우에만 패키지 버전을 지정합니다. 이상적으로 품질 보증 프로세스가 완료된 후 패키지 버전을 프로비저닝할 수 있습니다. 개발 팀이 패키지 만들기 요청의 성공 또는 실패를 얼마나 잘 패키지 경계를 정의했는지에 대한 "테스트"로 사용할 수 없습니다. 패키지 아티팩트의 버전을 지정하지 않고 이를 수행할 수 있는 방법이 있습니다.
• 이상적인 최종 상태가 지원해야 하는 것 이상적인 패키징 전략은 빠르게 개발하고 배달할 수 있는 제어되고 안정적인 Salesforce 릴리스를 허용합니다. 조직 전체에서 너무 많은 패키지를 정의하면 개발 팀에 새로운 종류의 복잡성과 지체 지점을 야기할 수 있습니다. 조직이 과도하게 모듈화되면 릴리스가 느리고 어려울 수도 있습니다. 먼저 의미 있는 단일 패키지의 몇 가지 버전을 구축하고 릴리스합니다. 후속 패키지를 증분적으로 파생합니다. 비즈니스에 적합한 릴리스 케이던스가 있는 경우 패키지 도입을 중지합니다. 비즈니스 요구 사항이 변경되거나 릴리스 품질이 저하될 경우 시간에 따른 리팩터 패키지 이상적인 패키지 끝점은 주관적입니다.

패키지를 정의하는 방법에 상관없이 효과적인 종속성 관리를 통해 해방된 패키지를 성공적으로 버전화할 수 있습니다.

아래의 모형 및 안티모형 목록은 Salesforce 패키징의 올바른 (그리고 나쁜) 느슨한 커플링을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다.

Salesforce 도구에 대해 자세히 알아보려면 Composable과 관련된 도구를 참조하십시오.

Salesforce 솔루션의 컨텍스트에서 종속성 관리는 패키지의 메타데이터와 해당 패키지가 설치될 조직의 메타데이터 간 관계를 식별하고 구조화함을 의미합니다. 종속성 관리는 안정적인 패키지 아티팩트 개발의 핵심 부분입니다.

종속성은 완벽하게 분리되고 연결하게 연결된 기능 단위를 만드는 노력과 상충될 수 있습니다. 이상적인 엔지니어링 상태에서 부드럽게 연결된 시스템에는 단위 간의 종속성이 없습니다. 그러나 실제에서는 모든 종속성을 제거하는 것이 실용적이지 않습니다.

종종 시스템을 읽을 수 있음과 비즈니스 친화적인 기능 유닛을 사용하는 것 사이의 균형을 유지하려면 시스템의 모든 유닛을 완벽하게 격리해야 합니다. 보다 실용적인 측면에서 Salesforce Platform의 표준 기능을 통해 제공되는 핵심 서비스는 모든 Salesforce 솔루션에 대한 핵심, 순 양성 종속성을 만듭니다. 많은 내장 확장성, 성능 및 보안 이점은 플랫폼에 얼마나 심층적으로 통합되어 있는지에 달려 있습니다. 패키지 가능한 Salesforce 솔루션을 설계할 때 패키지 종속성이 본질적으로 나쁜 것은 아닙니다. 부족한 종속성 관리 는 나쁜 것입니다.

Salesforce 패키징을 통한 효과적인 종속성 관리를 통해 개발 및 서비스 점검 팀이 다음을 수행할 수 있습니다.

• 신규 프로젝트에 더 빠르게 온보딩하고 제한된 환경 액세스
• 신속한 변경 개발 및 테스트
• 작고 구체적인 서약에서 복잡한 기능을 어떻게 전달해야 하는지 이해
• 릴리스 케이던스 제어 및 시스템 서비스 점검/릴리스 중단 기간 줄이기
• 모든 환경에서 예측 가능한 롤백 불량 변경 사항

Salesforce를 통한 종속성 관리에 대한 기술은 매우 간단합니다.

• 메시징 및 이벤트 매김을 사용하여 구성 요소 간에 상태가 있는 정보 또는 상태가 없는 정보의 편리한 전달을 처리합니다.
• 사용자 정의 메타데이터 유형을 사용하여 동적 런타임 정보를 제공하고 종속성 삽입 패턴을 지원합니다.
• Apex 개발자가 추상 또는 가상 클래스를 사용하도록 합니다.

마지막으로 선언적 및 프로그램 방식 개발 전반에서 조직에서 허용되는 설계 패턴을 결정해야 합니다. 가장 중요한 고려 사항(아키텍처상)은 종속성을 줄이기 위해 더 많은 엔지니어링 복잡성을 추가할 위치와 앱 빌더 워크플로를 간소화하기 위해 더 많은 종속성을 허용해야 하는 위치를 정의하는 것입니다.

패키지에 종속성 관리 전략을 구축할 때 패키지 단위의 두 가지 기본 구성 원칙인 가로 및 세로를 고려하십시오.

• 수평 경계 가로 패러다임에서 둘 이상의 패키지에 필요한 기능은 가로 레이어로 추상화됩니다. 그러면 가로 레이어가 공통 기능의 소스가 되고 선언된 종속성을 통해 액세스됩니다. 패키지 전반의 중복 기능을 최소화하는 것이 종속성 최소화보다 더 좋습니다.
• 수직 경계 세로 패러다임은 시스템 부품 간의 격리 및 릴리스 커플링을 극대화합니다. 공유 기능은 제한되며 유사한 작업이 단위 전체에 표시될 수 있습니다. 패키지 단위 간의 격리를 극대화하기 위해 종속성이 엄격하게 제한됩니다.

이는 두 가지 중 하나의 결정이 아닙니다. 필요에 따라 세로 및 가로 패러다임을 혼합할 수 있습니다. 패키지를 시작하는 가장 빠른 방법은 가로 서비스 계층을 만드는 것입니다. 패키지 채택의 규모와 복잡성이 증가함에 따라 더 많은 세로 단위를 추상하면 복잡한 환경 설정 프로세스 또는 개발자 온보딩을 간소화하는 데 도움이 됩니다.

예를 들어 두 개의 기능 단위(A 및 B)가 있는 시스템은 세로, 가로, 세로 가로 하이브리드 패러다임으로 정렬된 패키지 종속성을 사용하여 구조화할 수 있습니다.

선택한 패키지 구성 패러다임과 상관없이 유의해야 할 몇 가지 절대어가 있습니다.

• 패키지 간에 메타데이터를 복제하지 마십시오. 둘 이상의 패키지에 필요한 메타데이터는 종속으로 선언되는 하나 이상의 패키지로 추상화해야 합니다.
• Salesforce Platform 메타데이터의 내장 종속성을 사용합니다. 앱 빌더의 경우 Salesforce Platform에서 제공하는 내장형 서비스는 빠르게 구성할 수 있는 광범위한 기능을 제공합니다. 많은 서비스에 내장 종속성이 있으므로 하위 수준 기능 단위로 추상화하기가 어렵습니다. 지정된 메타데이터 유형의 경우 내장 종속성 스펙트럼에 따라 해당 유형이 어디에 속하는지 이해하고 이 이해를 사용하여 패키지 종속성 체인을 정의해야 합니다. 내장 종속성이 많은 표준 플랫폼 기능에 느슨한 커플링을 강제 적용하여 패키지 채택을 시작하지 마십시오. 더 높은 순위의 성능에 도달하면 값이 아닌 복잡성이 추가됩니다. 또한 표준 vs. 사용자 정의 안티 패턴에 빠지는 또 다른 방법입니다. 하단(최소 종속성)에서 메타데이터를 위로 패키징하고 시간에 따라 반복합니다.
• 자식 체인 조심해 개발자가 한 번에 여러 가지 다른 패키지로 변경 사항을 분할해야 하는 패키지 종속성 체인을 만들지 마십시오.
• 소스 제어에 대한 의미가 무엇인지 생각해보세요. 소스 제어에서 패키지를 관리하는 두 가지 기본 방법이 있습니다. 첫 번째는 폴더 내에서 격리된 패키지와 함께 단일 모노레포입니다. 두 번째는 자체 리포지토리에 분리된 패키지가 있는 여러 리포지토리입니다. 각 유형의 소스 전략을 장기간 관리하는 데는 복잡성이 있습니다. 개발자 온보딩 측면에서 수직 경계는 여러 리포지토리 패러다임에서 더욱 효율적입니다. 모노레포에서는 가로 경계를 더 이해할 수 있습니다. 다시 말해 아키텍처가 성숙해질 때 전략을 혼합하고 일치시킬 수 있습니다.

아래의 패턴 및 안티패턴 목록은 Salesforce 패키지에서 올바른(그리고 나쁜) 종속성 관리가 어떻게 보이는지 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별할 수 있습니다.

종속성 관리용 Salesforce 도구에 대해 자세히 알아보려면 구성 가능과 관련된 도구를 참조하십시오.

다음 표는 조직에서 조회(또는 구축)할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 더 많은 패턴을 찾으세요.

Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 설문 조사을 작성하고 다음에 표시할 내용을 알려주십시오.