Прочитайте о расписаниях обновления здесь.

Компонентные решения быстро и стабильно настраиваются. Система, созданная для компоновки, состоит из значимых единиц, или составных элементов, которые могут изящно работать друг с другом и могут быть легко заменены и выведены из эксплуатации. Внедрение компоновки в систему позволяет внедрить новые функции или удалить техническую задолженность путем реорганизации или повторной сборки отдельных единиц системы. Составимость позволяет ускорить и прогнозировать циклы доставки и выпуски, поскольку рабочие группы могут сосредоточиться на создании и предоставлении значимых функций посредством меньших изменений.

Компонентные системы позволяют предприятиям быстрее и с большей стабильностью адаптироваться — независимо от того, является ли стимул внутренним по отношению к предприятию или вызван внешними факторами. Сочетаемость помогает системам быть более устойчивыми и может помочь сделать решения и архитектурные схемы более намеренными.

Решения Salesforce можно сделать более составными, создав три ключевых привычки: разделение проблем, совместимость и пакетируемость. Ниже можно увидеть взаимосвязь этих привычек двумя способами: для одной единицы в составной системе и для нескольких единиц в составной системе.

Одна составная единица:

Составная система:

Одна из основополагающих концепций в области разработки программного обеспечения и архитектуры систем, разделение проблем предполагает выявление различных проблем в рамках более крупной системы, которые можно разделить на модульные единицы. Достижение четкого разделения проблем в системе требует создания значимых единиц для логики и функций приложения в системе. Небольшие единицы упрощают группам доставки и обслуживания приложения понимание того, как и где вносить изменения, с минимальными сбоями в работе большой системы. Более мелкие подразделения также позволяют более четко определить, как и где сосредоточить работу при решении проблемы технической задолженности и повысить общую читаемость системы.

Вы можете создать лучшее разделение проблем в организации Salesforce, ориентируясь на бизнес-возможности и управляя состоянием.

В системах Salesforce лучший подход к разделению проблем применяет бизнес-ориентированную перспективу для определения и систематизации модульных единиц (или возможностей) в системе. Это не похоже на инженерно-ориентированное представление, которое определяет единицы на основе их технических функций. Бизнес-ориентированная перспектива при разделении интересов требует систематизации кода и настроек в системе на основе обслуживания, предоставляемого бизнес-пользователям и бизнес-пользователям. Принятие такого подхода не означает игнорирования потенциала избыточных или дублирующих технических функций в системе. Скорее, это значит, что технические службы четко соотносятся с принципом организации, который в конечном итоге будет прозрачным для бизнеса.

Ориентация на бизнес-возможности помогает обеспечить максимально простую передачу данных между группами бизнес-анализа и обнаружения группам доставки. Если конструкторы приложений понятия не имеют, где их рабочие единицы соотносятся с вашей компонованной архитектурой, у вас будет беспорядок, а не компонованный ландшафт приложения. Нечеткие соотнесения между конечным состоянием, требуемым предприятием, и модульными единицами в организации также повышают шансы групп разработчиков или поставщиков на внедрение избыточных функций в систему.

Ниже перечислены рекомендации по ориентации функциональных единиц на бизнес-возможности.

• Начните с заданий, которые нужно выполнить. Сосредоточьтесь на задачах, которые должны быть выполнены (JTBD) пользователями и самим предприятием. Подход JTBD, впервые разработанный Тони Улуиком, фокусируется на понимании «работы», или истинной цели, которую люди пытаются выполнить, используя продукт или услугу. Это более высокий уровень абстракции, чем задачи, связанные с ролью пользователей или отдельные этапы бизнес-процесса. Например, задачи повторной проверки и проверки адресов могут относиться к функции более высокого порядка «создание единого представления клиента». После четкого понимания этих бизнес-возможностей более высокого порядка можно начать соотносить части системы с ними.
• Ориентация на возможности, а не на структуры отчетности. Внутренняя иерархия бизнес-единиц не является прокси-сервером значимых возможностей или задач. Внутренняя иерархия предприятия оказывает существенное влияние на процессы и структуры рабочей группы (не говоря уже о бюджетах). Это важные логистические соображения. Но функциональные потребности бизнеса работают на более высоком уровне абстракции, чем логистика. Если вы создаете модуль для обслуживания структуры отчетности, а не функции более высокого порядка, помните, что, возможно, вам придется предпринять дополнительные шаги для определения взаимосвязи модуля с бизнес-возможностями.
• Будьте круты. Начните с партнерства с предприятием, чтобы определить, какая возможность может работать для минимального жизнеспособного продукта (MVP). При определении возможности начните создавать MVP. При создании определите процессы, метаданные и события или сообщения, являющиеся центральными для создаваемой функциональной единицы. Определите процессы, метаданные и события или сообщения, являющиеся внешними зависимостями. По мере проектирования дополнительных функциональных единиц внедрять управление API и управление зависимостями для создания единиц, которые хорошо работают друг с другом (вместо создания изолированных единиц).

Список шаблонов и антишаблонов ниже отображает правильную (и плохую) ориентацию на бизнес-функции в решении Salesforce. Их можно использовать для проверки дизайна перед созданием или определения областей системы, требующих реорганизации.

Чтобы узнать больше об инструментах, доступных в Salesforce, чтобы лучше ориентироваться в бизнес- возможностях, см. Инструменты, связанные с компоновкой.

Управление государством сосредоточено на перемещении информации в системе в разные периоды времени. Эффективное управление состоянием позволяет приложениям обрабатывать сложные потоки данных или взаимодействия с минимальным количеством незапланированных или неопределенных результатов. Управление состоянием в модульной организации Salesforce означает создание четких путей для логических потоков внутри единиц и между ними, а также изящных путей для незапланированных алгоритмов выполнения. Управление штатами позволяет формировать последовательные потоки логики из модульных единиц приложения Salesforce. В большинстве случаев это требует совместимости для структурирования потока информации между единицами.

Трудности управления состоянием в слабо связанных единицах часто приводят к разработке монолитного приложения в Salesforce. Это видно на примере больших "монопотоков", которые построены в попытке оркестрации сложного процесса в рамках единственного потока. Другой пример - массовые классы Apex, которые организуют сложные процессы посредством кода спагетти или длинного ряда одноразовых методов. Эти типы архитектур приложений затрудняют рефакторинг и отладку и увеличивают время адаптации для новых участников рабочей группы или поставщиков. Они также уменьшают ценность приложений, доставленных в предприятие, поскольку функции не могут использоваться повторно.

Ниже перечислены рекомендации по управлению состоянием в модульной организации Salesforce.

• Решите, когда использовать шаблоны «Состояние» и «Без гражданства». Шаблоны состояния сохраняют сведения на протяжении пути выполнения, схемы без гражданства - нет. В слабосвязанной системе схемы без состояния позволяют быстрее и с меньшим количеством побочных эффектов рефакторинг компонентов. Однако, схемы без гражданства не подходят для всех способов использования. Если вы создаете компоненты для операций над данными, штатные схемы могут помочь с целостностью и согласованностью данных в ваших системах. Используйте статическую схему, если ваш компонент соответствует любому из следующих критериев:
  • Осознание размещения в большем пути выполнения важно для поведения компонента
  • Алгоритм компонента должен меняться на основе результатов действия в нисходящем направлении (например, его выполнение должно быть изменено на основе сообщений об откате/ошибке/успехе из компонентов в нисходящем направлении)
  • Компоненту необходимо дождаться окончания работы ответов от внешней системы или системы на выходе
• Создание значимых категорий для получения значимой информации. Состояние — это неоднозначный термин, который может применяться к столь обширному массиву информации в организации Salesforce (и за ее пределами), что сам по себе термин практически не имеет смысла. Таким образом, необходимым первым шагом к созданию шаблонов состояния является создание значимых категорий для наиболее важных путей выполнения состояния (или типов поведения состояния) в вашей системе. Ниже перечислены некоторые категории.
  • Навигация и формы
  • Операции базы данных
  • Пакетные и пакетные операции
  • Ошибки
• Определите состояния, связанные с данными, посредством транзакций базы данных. Встроенные алгоритмы платформы будут скрывать большинство рекомендаций по состоянию данных в Salesforce. Не пытайтесь управлять против или вокруг этого поведения. Создайте для него и с ним. Создайте решения, которые минимизируют или исключают логику распределенных транзакций. (Дополнительные сведения см. в разделе «Обработка данных»).
• Определение состояний, возникающих в функциональных единицах (и между ними). Собирая функциональные единицы в большие системы, помните о смешивании поведения компонентов без состояния и предотвращайте комбинации, которые могут создать бесконечные циклы или пробелы в обработке.
• Определите передачи. Определите, какие компоненты схемы сообщений или событий будут использовать для передачи данных, связанных с состоянием, в другую часть системы. Убедитесь, что вы создаете осведомленность о транзакциях и обработку компонентов. Не добавляйте логику распределенных транзакций в раздачи.
• Создание соотнесений между диаграммами процессов и состояниями. Диаграммы процессов содержат сведения о шагах, которые перемещают информацию по системе в разные периоды времени. Диаграмма состояния отображает фактические изменения в информации (состояние). Используйте часть нижнего колонтитула метаданных в формах диаграмм Salesforce для сбора изменяющегося состояния информации на каждом этапе процесса. Если вы разделяете диаграммы процесса и диаграммы состояния, обязательно свяжите их. Эту концепцию не следует путать со сбором данных о текущем и будущем состоянии процессов или системных ландшафтов в процессе проектирования и внедрения, поскольку речь не идет о информации, перемещаемой по системе.

Список шаблонов и антишаблонов ниже отображает, как корректно (и плохо) выглядит государственное управление в решении Salesforce. Их можно использовать для проверки дизайна перед созданием или определения областей системы, требующих реорганизации.

Чтобы узнать больше об инструментах Salesforce для управления состоянием, см. Инструменты, связанные с компоновкой.

Следующая таблица отображает выбор схем для поиска (или создания) в организации и антисхемы для избежания или нацеливания на исправление.

✨ Узнайте больше о схемах разделения проблем в Проводнике по шаблонам и антипаттернам.

В системе, созданной для совместимости, компоненты могут обмениваться информацией и эффективно работать вместе. Интерактивность - это ключ к тому, чтобы модульная система была составляющей, а не изолированной. Взаимосовместимость в слабо связанных системах может быть трудной задачей. Необходимо установить стандарты для последовательных методов интеграции, которые не подрывают независимость между единицами и общее разделение интересов в рамках системы.

Интерактивность также влияет на качество взаимодействий пользователя. Ваши пользователи ожидают, что данные, созданные в одной области (например, сведения о заказе), будут использоваться в другой (например, маркетинговые кампании), а ваши конструкторы ожидают, что, если они научатся что-то делать (например, создание потока или проверка подлинности в API), они найдут привычные методы работы при переходе к следующей проблеме. Неспособность проектировать интерактивность приведет к избыточной архитектуре, реплицированным данным, неэффективности процессов и увеличению расходов на разработку и поддержку.

Вы можете создать совместимость в модульных системах со службой сообщений и событием, а также с управлением API.

Сообщения и события - это два способа включения компонентов в системе для отправки и получения информации. По содержимому события и сообщения похожи. Ключевым отличием является поведение отправителя. Компонент, отправляющий сообщение, обычно отправляет данные в определенную цель и ожидает ответа от получателя. В отличие от этого, компонент излучает событие, когда что-то произошло. Конкретного назначения нет, как и ожидания ответа. Эти различия в поведении поддерживают разные схемы коммуникации. Сообщения поддерживают штатные схемы коммуникации, а события поддерживают схемы коммуникации без гражданства. (Дополнительную информацию об этом различии см. в разделе «Управление государством».)

Важно согласовывать рабочие группы по протоколам и сценариям использования для службы сообщений и события. Нечеткие стандарты могут привести к смешиванию схем в вашей системе, что приведет к:

• Проблемы производительности и масштабируемости, когда к конкретному сценарию использования применяются неправильные схемы
• Непоследовательная обработка, из-за которой система кажется нестабильной конечным пользователям
• Увеличение времени устранения неполадок и усложнение процессов обслуживания

Ниже перечислены рекомендации по созданию более слабо связанных структур в организации Salesforce при создании сообщений и событий.

• Определение сценариев использования синхронизации и асинхронизации. Событие позволяет использовать слабо связанные, не имеющие гражданства и асинхронные коммуникации в системе. Служба сообщений позволяет использовать более жестко контролируемые, контролируемые и синхронные схемы связи. Решая, когда использовать сообщения или события, необходимо решить, нужно ли синхронизировать (и потенциально блокировать) коммуникацию с асинхронной и неблокирующей.
• Тщательно определите структуры данных. Структура информации, проходящей между компонентами, является важной частью поддержания управляемости и согласованности слабо связанной системы. (Дополнительную информацию см. в разделе «Управление API».) Ключевым фактором при создании сообщения или события является частота изменения структуры информации. После определения и внедрения сообщения или структуры события в вашей системе обработка обновлений может быть затруднена, особенно если событие или сообщение уже используется для отправки информации во внешнюю систему.
• Сообщения правильного размера. В общем, рекомендуется держать размер сообщений небольшим. Однако существует также баланс между размером сообщения и объемом сообщения. Системы могут быстрее обрабатывать меньшие объемы данных. Акт обработки сопровождается дополнительными накладными расходами, поскольку получателям нужно распаковывать, интерпретировать и определять, что делать с полученной информацией. Выполнение этих этапов может занять ничтожно мало времени, но они могут привести к увеличению нагрузки на системы в масштабах. Избегайте дизайна, требующего, чтобы компоненты в системе обрабатывали много маленьких сообщений последовательно для выполнения части работы. Чтобы правильно определить размер сообщений, рекомендуем создать минимальные компоненты данных в нисходящем направлении для успешной обработки и обработки отправленной информации, не полагая, что каждый компонент в нисходящем направлении сможет запрашивать или обрабатывать многочисленные дополнительные сообщения.
• Создание для масштабируемости. Нестрого связанные компоненты могут упростить масштабирование архитектуры. Устранение кросс-зависимостей компонентов позволяет рабочим группам работать над повышением производительности или масштабируемости любого отдельного компонента с минимальным влиянием на другие. Однако, слабо связанные компоненты также создают значительные сложности в архитектуре в масштабах (особенно когда дело касается управления состоянием). Определите процессы, которые должны иметь более тесно связанную логику или зависимости для действительных взаимодействий пользователя или соображений целостности данных, и не пытайтесь внедрить схемы на основе асинхронизации/событий в эти процессы. Используйте схемы на основе синхронизации/сообщений и правильную обработку ошибок.

Список шаблонов и антишаблонов ниже отображает, как правильные (и плохие) сообщения и события выглядят в решении Salesforce. Их можно использовать для проверки дизайна перед созданием или определения областей системы, требующих реорганизации.

Чтобы узнать больше об инструментах службы сообщений и событий Salesforce, см. Инструменты, связанные с компоновкой. Дополнительные сведения о выборе схемы или инструмента события для данного сценария использования см. в Руководстве архитектора по архитектуре на основе событий в Salesforce.

Создание корректного управления интерфейсом программирования приложений (API) в решении Salesforce позволяет отдельным компонентам системы следовать предсказуемым схемам коммуникации. Salesforce предоставляет встроенные безопасные API для использования в общении с системами за пределами Salesforce. (Дополнительные сведения об API Salesforce Platform см. в разделе Основы архитектуры.)

Эффективное управление API в решениях Salesforce является ключом к созданию по-настоящему составных архитектур. Он позволяет компонентам внутри организации Salesforce эффективно отправлять и получать информацию. Это также позволяет конструкторам решений выполнять четкие протоколы взаимодействия создаваемых компонентов с другими компонентами системы и помогает им заранее определить плохие внедрения. Кроме того, это позволяет конструкторам решений более узко сосредоточиться на конкретном создаваемом или реорганизуемом компоненте, что повышает производительность и качество.

Управление API на уровне предприятия является отдельной темой, и это лучше всего достигается с помощью универсального инструмента управления API. (Дополнительную информацию о перспективах MuleSoft по данной теме см. в разделе Что такое управление API?.)

Ниже перечислены рекомендации по созданию возможностей управления API в решениях Salesforce.

• Считайте API предсказуемыми схемами или контрактами для связи. Тип данных переменных ввода или вывода, имена переменных, части информации, которые должны (или не должны) отображаться в заданной схеме — это ключи к эффективному управлению API. Эти определения должны отображаться в стандартах проектирования, и рабочие группы должны иметь возможность узнать, как эти определения внедрены в определенных частях системы посредством документации. Один из способов просмотра трудностей объединения изменений из новой разработки в среду интеграции - это увидеть их как свидетельство того, где вы плохо внедрили коммуникации API (или, возможно, вообще не внедрили определение API).

• Не ограничивайте мысли об API только программированием. В данном контексте API определяется согласованностью структур сообщений и переменных в этом сообщении. Если эта последовательность сохраняется, API можно внедрить в код, а также в декларативные настройки, например, в модульные автоматически запущенные (или запущенные событиями платформы) потоки или даже шаблоны потоков. Основывайте решения на том, что определять в коде по сравнению с потоками, не на внедрении API, а на пакетируемости и тестируемости.

• Упростите жизненный цикл и версию. Как и все части разработки приложения, API имеют жизненный цикл: определение, создание, тестирование, развертывание и обслуживание (включая вывод из эксплуатации). Salesforce Platform API выпускает несколько версий в течение календарного года из-за быстрого цикла выпуска платформы. (Дополнительную информацию об этом алгоритме можно прочитать в Основах архитектуры Salesforce.) Это означает, что API платформы имеют достаточно сложный жизненный цикл, поскольку несколько версий определенного API должны поддерживаться и быть доступны клиентам Salesforce. Этот уровень сложности подходит для сценариев использования PaaS, но, скорее всего, он не нужен для архитектур решений на платформе (см.: Антишаблоны чтения). Сосредоточьтесь на определении четкой цели API (например, обработка ошибок) и четких базовых определений. Рекомендуем использовать только одну версию каждого API.

• Сделайте API обнаруживаемыми, доступными и управляемыми. Задокументируйте API, чтобы потенциальные потребители могли легко находить доступные API-интерфейсы для подключения к ним. АИП должны функционировать без сбоев как часть возможностей.

• Будьте круты. Сосредоточьтесь на определении и внедрении только одного внутреннего API одновременно. Таким образом, вы сможете быстро итерировать определение API, найти подходящую форму для одной поддерживаемой версии и создать рекомендации на основе опыта внедрения.

Список шаблонов и антишаблонов ниже отображает, как правильно (и плохо) выглядит управление API в решении Salesforce. Их можно использовать для проверки дизайна перед созданием или определения областей системы, требующих реорганизации.

Чтобы узнать больше об инструментах, доступных в Salesforce для создания большей совместимости, см. Инструменты, связанные с компоновкой.

Следующая таблица отображает выбор схем для поиска (или создания) в организации и антисхемы для избежания или нацеливания на исправление.

✨ Ознакомьтесь с дополнительными схемами совместимости в Проводнике по шаблонам и антипаттернам.

Создание пакетируемости в организации Salesforce означает, что функции в организации поступают из единиц, которые можно разработать и развернуть независимо и надежно, в виде пакетов. В идеале эти единицы определяются как тип пакета второго поколения (разблокированный пакет или управляемый пакет для СВУ). Примечание: Поскольку в высококачественных решениях используются только эти типы пакетов, управляемые пакеты первого поколения здесь не рассматриваются.

Одно дело определить разделения проблем и создать функциональные единицы в организации Salesforce. Другое дело, когда зависимости распутываются и управляются достаточно четко, чтобы успешно версировать эти единицы как артефакты пакета. Достижение такого уровня стабильности и изоляции метаданных требует значительного уровня зрелости DevOps (и архитектурной). Это также ускоряет время разработки, улучшает работу конструктора приложений и обеспечивает предсказуемость и контроль над выпусками и управлением выпусками. Не каждая организация сможет поддерживать инфраструктуру, необходимую для определения, обслуживания и разработки эффективных пакетов. Но достижение пакетируемости должно быть конечной целью почти для каждой организации Salesforce.

Вы можете создать пакетируемость в решениях Salesforce, сосредоточившись на свободной связи и управлении зависимостями.

В системе со свободной сцепкой отдельные детали не сильно связаны друг с другом. Многие преимущества составной системы связаны со слабой муфтой. В пакетируемых системах достижение свободной связи между пакетами (и установка организаций) позволит вам иметь четко определенные пакеты и более продуктивные циклы разработки для рабочих групп, работающих с пакетами.

Salesforce Platform позволяет создавать пакеты, тесно связанные с отдельной организацией. Эта возможность позволяет определять функциональные единицы и экспериментировать с правильным разделением проблем в вашей организации по мере достижения зрелости упаковки. Однако, если вы выберете этот метод, вы поймете мало преимуществ действительно пакетируемых метаданных, включая разработку под управлением источника, возможность использования версий и стабильность артефактов. Скорее всего, вы продолжите испытывать недостатки жестко связанной системы, включая:

• Отдельные точки сбоя, приводящие к сбоям и проблемам производительности
• Медленное, непредсказуемое развертывание
• Трудные, сложные циклы отладки и устранения неполадок
• Проблемы с масштабом и производительностью

Конечная цель любой пакетируемой системы Salesforce - это слабо связанные пакеты.

Ниже перечислены рекомендации по разделению метаданных Salesforce на эффективные пакеты.

• Какие настройки являются данными в сравнении с метаданными. Когда речь заходит о пакетируемости, Salesforce Platform обрабатывает данные и метаданные совершенно по-разному. Важно понимать, какие функции в вашей организации являются метаданными или данными. Данные не могут быть добавлены в пакетные единицы. Когда вы решаете, с чего начать извлечение функций в пакетную единицу, вашим рабочим группам нужно решить, следует ли вообще исключить настройки, сохраненные как данные, из пакета или реорганизовать их во внедрение на основе метаданных.
• Как пакетирование повлияет на рабочие группы. Логистическая реальность упаковки Salesforce такова, что большая часть работы по производству и выпуску версии пакета требует навыка работы с технологиями Salesforce CLI и/или CI/CD. Это значит, что настройки с низким кодом и программные настройки потребуют времени и внимания от человека, способного работать с технологией DevOps, связанной с пакетом. В зависимости от того, как рабочая группа управляет доставкой функций, внедрение пакета может привести к значительному замедлению или блокировке работы разных рабочих групп в организации. Вам нужно определить, смогут ли рабочие группы управлять доставкой функций посредством пакетирования, и составить план по устранению пробелов в навыках или кадрах. Решения могут включать внедрение парного программирования или внедрение заданий CI/CD для сред разработки.
• Как пакетирование изменит стратегии среды. В жизненном цикле разработки под управлением пакета ранняя работа должна выполняться в начальных организациях. Эти временные среды разработки, управляемые источником, позволяют ускорить циклы. Они также поддерживают более детализированный доступ к среде для рабочих групп разработчиков и большую изоляцию от производства. Чем больше зависимости пакетов от непакетированных метаданных или данных, существующих только в безопасной или производственной среде, тем меньше вероятность того, что рабочие группы смогут реально использовать стартовые организации. Вы можете включить отслеживание источников в безопасных средах, чтобы разрешить схемы разработки, управляемые источниками, в средах не стартовых организаций, но ваши группы разработчиков не смогут воспользоваться скоростью и повторяющейся скоростью стартовых организаций.
• Как версии пакета связаны с выпусками. Спланируйте, как часто и на каком этапе разработки должна происходить версия пакета. Запросы версии пакета ограничены (на организацию) на круглосуточной основе. Рекомендуем использовать версию пакета только в том случае, если содержимое пакета не нуждается в изменении. В идеале, вы предоставите версии пакета после завершения процессов обеспечения качества. Не разрешайте группам разработчиков использовать успех или неудачу запросов на создание пакета в качестве «проверки» правильности определения границ пакета. Существуют способы сделать это без попытки версии артефакта пакета.
• Что идеальное конечное состояние должно поддерживать. Идеальная стратегия пакетирования позволяет быстро разрабатывать и поставлять управляемые стабильные выпуски Salesforce. Определение слишком большого количества пакетов в организации может привести к новым типам сложностей и преград для групп разработчиков. Излишне модульизированная организация также может привести к медленным и сложным выпускам. Начните с создания и выпуска нескольких версий одного значимого пакета. Извлеките дополнительные пакеты инкрементно. Прекратите вводить пакеты, если у вас есть каденция выпуска, хорошо обслуживающая ваше предприятие. Пакеты факторов с течением времени, если бизнесу нужны изменения или качество выпуска падает. Идеальное конечное состояние пакета является субъективным.

Вне зависимости от способа определения пакетов, версия пакета будет успешной только посредством эффективного управления зависимостями.

Ниже приведен список схем и антисхем, отображающих правильный (и некачественный) свободный вид соединения для упаковки Salesforce. Их можно использовать для проверки дизайна перед созданием или определения областей системы, требующих реорганизации.

Чтобы узнать больше об инструментах Salesforce, которые помогут вам создать больше пакетируемости, см. Инструменты, связанные с компоновкой.

В контексте решения Salesforce управление зависимостями означает определение и структурирование взаимосвязей между метаданными в пакетах и метаданными в организациях, в которые будут установлены эти пакеты. Управление зависимостями является ключевой частью разработки артефактов стабильного пакета.

Зависимости могут вступать в противоречие с усилиями по созданию идеально разделенных и тесно связанных функциональных единиц. В идеальном инженерном состоянии слабосвязанная система не имеет зависимостей между единицами. Однако в реальном мире ликвидация всех зависимостей нецелесообразна.

Зачастую баланс между обеспечением читаемости систем и использованием функциональных единиц, удобных для бизнеса, требует компромиссов с точки зрения идеальной изоляции единиц системы. Если говорить более прагматично, то базовые услуги, предоставляемые стандартными функциями Salesforce Platform, создают ключевые, чистые положительные зависимости для любого решения Salesforce. Многие встроенные преимущества масштабируемости, производительности и безопасности зависят от того, насколько глубоко они интегрированы в платформу. При создании пакетируемых решений Salesforce важно помнить, что зависимости пакета не являются плохими. Плохое управление зависимостью - это плохо.

Эффективное управление зависимостями посредством пакетирования Salesforce означает, что группы разработки и обслуживания могут:

• Быстрое адаптирование к новым проектам и ограниченный доступ к среде
• Быстрая разработка и тестирование изменений
• Понимание того, как сложные функции должны предоставляться в более мелких, конкретных обязательствах
• Управление каденциями выпуска и уменьшение окон обслуживания/отключения выпуска системы
• Предсказуемый откат неблагоприятных изменений в любой среде

Методы управления зависимостями с помощью Salesforce достаточно просты:

• Используйте сообщения и события для обработки изящной передачи государственной информации или информации без гражданства между компонентами.
• Используйте типы настраиваемых метаданных для предоставления динамических сведений о среде выполнения и поддержки схем впрыска зависимости.
• Разработчики Apex могут использовать абстрактные или виртуальные классы.

В итоге, вам нужно будет определить схемы проектирования, разрешенные в вашей организации в декларативной и программной разработке. Самые важные рекомендации (архитектурно) — определить, куда вы хотите добавить больше инженерной сложности, чтобы иметь меньше зависимостей, и где нужно терпеть больше зависимостей, чтобы упростить бизнес-процессы конструктора приложений.

При встраивании стратегий управления зависимостями в пакеты учитывайте два основных принципа организации единиц пакета: горизонтальный и вертикальный.

• Горизонтальные границы. В горизонтальных парадигмах функции, которые могут понадобиться нескольким пакетам, извлекаются в горизонтальный слой. Горизонтальные слои потом становятся источником общих функций и открываются посредством объявленной зависимости. Минимизация избыточных функций в пакетах предпочтительнее минимизации зависимостей.
• Вертикальные границы. Вертикальные парадигмы обеспечивают максимальную изоляцию и свободную связь между частями системы. Общедоступные функции ограничены, и аналогичная работа может отображаться в единицах. Зависимости строго ограничены, чтобы максимально изолировать единицы пакета.

Обратите внимание, что это не является решением «или-или». При необходимости можно смешивать вертикальные и горизонтальные парадигмы. Часто самый быстрый способ начать работу с пакетом - это создать горизонтальные слои обслуживания. По мере расширения масштабов и сложности внедрения пакета абстрагирование большего количества вертикальных единиц поможет упростить процессы настройки сложной среды или адаптацию разработчика.

Например, система с двумя функциональными блоками (А и Б) может быть структурирована с зависимостями пакета, расположенными в вертикальной, горизонтальной и вертикально-горизонтальной гибридных парадигмах.

Вне зависимости от выбранной парадигмы организации пакета, необходимо учитывать некоторые абсолютные значения:

• Не дублируйте метаданные в пакетах. Метаданные, необходимые нескольким пакетам, должны быть абстрагированы в один или несколько пакетов, объявленных зависимостями.
• Используйте встроенные зависимости метаданных Salesforce Platform. Для конструкторов приложений встроенные службы, предлагаемые Salesforce Platform, предоставляют много функций, которые можно быстро настроить. Многие из этих служб имеют встроенные зависимости, которые затрудняют их абстракцию в функциональные единицы низкого уровня. Для заданного типа метаданных необходимо понимать, где они находятся в спектре встроенных зависимостей, и использовать это понимание для определения цепочек зависимостей пакета. Не начинайте внедрение пакета, попробовав силовую связь в части стандартных функций платформы с большим количеством встроенных зависимостей. Это добавит сложности (не ценности) при достижении возможностей более высокого порядка. Это также еще один способ попасть в стандартные по сравнению с обычными шаблонами. Упакуйте метаданные снизу (меньше зависимостей) вверх — и повторяйте в динамике.
• Следите за цепочками зависимостей. Избегайте создания цепочек зависимостей пакета, которые потребуют от разработчиков одновременного разделения изменений на множество разных пакетов.
• Подумайте, что имеет смысл делать для контроля источников. Существует два основных способа управления пакетами в контроле источников. Первый — это единый монорепо с изолированными пакетами внутри папок. Второе - несколько репо с изолированными пакетами в собственных репо. Управление каждым типом исходной стратегии, долгосрочной, сопряжено с трудностями. С точки зрения адаптации разработчика, вертикальные границы более эффективны в нескольких парадигмах РЕПО. Горизонтальные границы более понятны в монорепо. Опять же, можно смешивать и сопоставлять стратегии по мере взросления архитектуры.

Список шаблонов и антишаблонов ниже отображает, как правильно (и плохо) выглядит управление зависимостями в пакетах Salesforce. Их можно использовать для проверки дизайна перед созданием или определения областей системы, требующих реорганизации.

Чтобы узнать больше об инструментах Salesforce для управления зависимостями, см. Инструменты, связанные с компоновкой.

Следующая таблица отображает выбор схем для поиска (или создания) в организации и антисхемы для избежания или нацеливания на исправление.

✨ Ознакомьтесь с дополнительными схемами пакетируемости в Проводнике по шаблонам и антипаттернам.

Помогите нам поддерживать актуальность Salesforce «Хорошо архитектура». Пройдите опрос, чтобы предоставить отзыв об этом содержимом и сообщить, что вы хотите видеть дальше.