Схемы архитектуры
Узнайте больше о оптимизации ресурсов и затрат → Ваши обязанности оптимизации
Эта страница предоставляет комплексное руководство по схемам для архитектурных проблем, включительно с функциональными единицами, разделением проблем, государственным управлением, управлением API и службой сообщений. Эти схемы определяют долгосрочный успех решения посредством обдуманных проектных решений о границах обслуживания, схемах доступа к данным и обязанностях компонентов.
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Классы Apex | ✅ Классы обслуживания придерживаются принципа единой ответственности с именами, четко обозначающими цель (AccountService, OrderProcessor, InventoryManager). Каждый класс обслуживания фокусируется на одном домене или бизнес-возможности. Методы в классах обслуживания имеют единые сфокусированные обязанности под 20 строками. |
| Триггеры | ✅ Триггеры делегируют классам средства обработки, а не содержат бизнес-логику напрямую. Шаблон средства обработки триггеров, используемый последовательно с четкими именами методов по контексту (handleBeforeInsert, handleAfterUpdate). Классы обработчика систематизируют логику по событию триггера с одной ответственностью на метод. |
| Веб-компоненты Lightning | ✅ Компоненты следуют принципу единой ответственности с понятными интерфейсами реквизита для конфигурации. Каждый LWC фокусируется на одной проблеме пользовательского интерфейса (отображение данных, ввод пользователя, навигация). Компоненты, предназначенные для компоновки, а не для монолитных внедрений. |
| Слой обслуживания | ✅ Классы обслуживания инкапсулируют бизнес-логику, не зависимую от точки входа (триггер, API, поток, пакет). Один класс обслуживания обрабатывает несколько контекстов вызовов без дублирования. Уровень обслуживания разделяет бизнес-правила и проблемы доступа к презентации и данным. |
| Многоразовые компоненты | ✅ Компоненты, предназначенные для повторного использования в нескольких проектах и группах. Алгоритм, управляемый конфигурацией, использующий типы настраиваемых метаданных, включает изменения поведения без развертывания кода. Вызываемые действия открывают логику Apex как декларативные структурные элементы, используемые в потоке и внешней оркестрации. |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Класс бога | ⚠️ Избегайте накопления чрезмерной ответственности в одном классе. Разделите большие классы (>500 строк) на целевые классы с одной ответственностью. Перестройте классы, если они обрабатывают несколько несвязанных проблем (OrderProcessor не должен также обрабатывать отправку сообщений эл. почты и составление отчетов). |
| Смешанные проблемы | ⚠️ Избегайте смешивания логики триггера, бизнес-правил и доступа к данным в отдельных классах. Отделите логику презентации от бизнес-логики в контроллерах. Держите проблемы интеграции отдельно от базовой логики домена. |
| Логика триггера в триггерах | ⚠️ Избегайте встраивания бизнес-логики напрямую в файлы триггера. Никогда не используйте триггеры строки 300+ с вложенными условиями. Всегда делегируйте классы средства обработки с четкой организацией методов по контексту триггера. |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Бизнес-логика | ✅ Бизнес-правила, централизованные в классах обслуживания, а не разбросанные по триггерам, контроллерам и пакетным классам. Классы домена инкапсулируют алгоритм на уровне записи (проверка, стандартные значения, производные значения) последовательно, вне зависимости от способа входа записей в систему. Логика используется повторно через уровень обслуживания, а не дублируется в точках входа. |
| Доступ к данным | ✅ Доступ к данным, абстрагированный за классами схемы хранилища или селектора. Запросы SOQL, централизованные в классах селектора (AccountSelector, OpportunitySelector), обеспечивающие последовательность списков полей и условий WHERE. Схема хранилища позволяет тестировать с помощью инсценировки источников данных без изменения бизнес-логики. |
| Интерфейсные контракты | ✅ Компоненты взаимодействуют посредством явных интерфейсов, а не сведений о внедрении. Интерфейсы Apex определяют контракты между слоями. Конфигурация настраиваемых метаданных определяет границы поведения. События платформы предоставляют контракты службы сообщений между производителями и потребителями. |
| Границы модуля | ✅ Граничные контексты определяют четкие границы ответственности для моделей данных и бизнес-правил. Каждый модуль несет ответственность за данные, автоматизацию и бизнес-логику. Модули взаимодействуют посредством заданных API, а не напрямую предоставляют общий доступ к объектам базы данных. Документация четко определяет, какая рабочая группа несет ответственность за объекты и услуги. |
| Поток зависимости | ✅ Зависимости движутся в одном направлении (презентация → бизнес → данные). Базовая бизнес-логика не зависит ни от чего внешнего, что включает независимую эволюцию. Проблемы инфраструктуры (регистрация, кэширование, внешние API) зависят от бизнес-логики посредством интерфейсов, а не наоборот. |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Дублирование логики | ⚠️ Избегайте дублирования бизнес-логики в триггерах, конечных точках API и пакетных классах. Централизация в уровне обслуживания и повторное использование в точках входа. При каждом отображении одного бизнес-правила в нескольких классах извлеките его в общедоступную службу. |
| Доступ к данным рассеян | ⚠️ Избегайте запросов SOQL, разбросанных по классам триггеров, контроллеров и пакетов с несогласованными списками полей и условиями WHERE. Централизация запросов в классах селектора, обеспечивающая согласованные схемы и включение оптимизации LDV в одном расположении. |
| Бизнес-логика в триггерах | ⚠️ Избегайте правил проверки, вычислений полей и оркестрации бизнес-правил, встроенных напрямую в код триггера. Перейдите к классам обслуживания или классам домена. Триггеры должны быть тонкими, фокусироваться только на делегировании соответствующим обработчикам. |
| Бизнес-логика в контроллерах | ⚠️ Избегайте сложных расчетов, проверки или манипуляций данными в методах контроллера Aura/LWC. Контроллеры должны оркестрировать вызовы уровня обслуживания, а не внедрять бизнес-правила напрямую. |
| Круговые зависимости | ⚠️ Избегайте пакетов или классов с круговыми зависимостями, где А зависит от Б, а Б зависит от А. Решите проблему, извлекая общие проблемы в отдельный модуль, преобразовывая направление зависимости или используя коммуникацию на основе событий для разрыва связи. |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Кэш платформы (разделение организации) | ✅ Часто доступные справочные данные, кэшированные в разделе организации, включая поиск настраиваемых метаданных, значения раскрывающегося списка, параметры конфигурации и вычисленные результаты дорогостоящих операций. Стандартный TTL, настроенный на основе волатильности данных (часы для ежемесячно меняющихся справочных данных, минуты для часто обновляемой конфигурации). Стратегия кэш-ключа предотвращает столкновения в разных типах данных. |
| Кэш платформы (разделение сеанса) | ✅ Настройки пользователя, вычисленные данные персонализации и состояние сеанса, хранящиеся в кэше сеанса. Кэш сеанса не используется для данных, которые должны быть общедоступны пользователям. Стратегия аннулирования кэша обрабатывает обновления пользовательских предпочтений надлежащим образом. |
| Служба данных Lightning | ✅ LDS предоставляет автоматическое кэширование клиентских записей для веб-компонентов Lightning. Стандартные операции CRUD используют LDS, а не настраиваемые контроллеры Apex. LDS устраняет лишние перелеты сервера и предоставляет оптимистичные обновления пользовательского интерфейса. Компоненты используют общий кэш LDS на странице. |
| Типы настраиваемых метаданных | ✅ Конфигурация и правила поведения, сохраненные в типах настраиваемых метаданных, а не жестко запрограммированные в классах. Настраиваемые метаданные, развертываемые в средах посредством наборов изменений или разработки на основе источников. Изменения настраиваемых метаданных не требуют полного цикла развертывания. Запросы кэширования настраиваемых метаданных в кэше платформы для повышения производительности. |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Запрос в цикле | ⚠️ Избегайте выполнения SOQL в циклах итерации. Запросите все нужные записи в одном операторе SOQL вне циклов. Систематизируйте результаты в соотнесениях по коду родителя для поиска во время итерации. Это самая распространенная антипаттерн Salesforce. |
| Повторяющиеся запросы | ⚠️ Избегайте многократных запросов одних и тех же настраиваемых метаданных, настраиваемых параметров или справочных данных на транзакцию. Запросите один раз, кэшируйте в кэше платформы или статической переменной транзакции, повторно используйте в транзакции. |
| Стратегия отсутствия кэша | ⚠️ Избегайте повторяющихся запросов часто используемых справочных данных без кэширования. Внедрите кэш платформы для настраиваемых метаданных, конфигурации и вычисленных результатов. Определите соответствующий TTL на основе волатильности данных. |
| Кэш без проверки | ⚠️ Избегайте кэширования данных без учета стратегии аннулирования. Определите TTL кэша, соответствующий частоте обновления. Внедрите ручную очистку кэша при изменении исходных данных, если одного TTL недостаточно. |
| Неуправляемое состояние сеанса | ⚠️ Избегайте предположения, что состояние сеанса сохраняется в навигации страницы без проверки. Компоненты Lightning должны выполнять обновление состояния при загрузке страницы. Используйте Lightning Data Service для автоматической синхронизации состояния. |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Планирование архитектуры решений | ✅ Планирование архитектуры выполняется до значительных инвестиций в создание, включая анализ требований (функциональных и нефункциональных), анализ контролирующих ограничений для ожидаемых объемов данных, выбор схемы, соответствующей требованиям, и проектирование компонентов, определяющих основные компоненты и интерфейсы. |
| Выбор схемы проектирования | ✅ Проверенные схемы дизайна Salesforce применяются последовательно: Схема уровня обслуживания для повторного использования бизнес-логики, хранилище/схема селектора для абстракции доступа к данным, схема стратегии для сменных алгоритмов, схема домена для поведения на уровне записи, схема средства обработки триггеров для последовательной организации триггера. |
| Записи решений архитектуры | ✅ Важные архитектурные решения, документированные в ADR, хранящиеся в управлении версиями. В ОРР учитывается контекст (факторы, влияющие на деятельность предприятий, технические ограничения), решение (выбранное), рассмотренные альтернативы (причины отклонения другими сторонами) и последствия (компромиссы, техническая задолженность, триггеры пересмотра). |
| Создание по сравнению с оценкой покупки | ✅ Оценка AppExchange предшествует настраиваемым решениям по разработке с использованием анализа общей стоимости владения. Критерии оценки включают стратегическую ценность (конкурентный дифференциатор по сравнению с товаром), сравнение TCO (усилия по созданию, обслуживание, затраты на модернизацию), сложность интеграции и стоимость выхода, если решение окажется неадекватным. |
| Анализ пределов управления | ✅ Архитектурное планирование определяет, какой управляющий ограничивает дизайн большинства ограничений, учитывая ожидаемые объемы данных и схемы транзакций. Транзакции, предназначенные для потребления менее 80% от любого отдельного управляющего ограничения в пиковых условиях. Прибыль, созданная для роста, будущих функций и непредвиденных схем использования. |
| Оценка риска | ✅ Технические риски, определенные для архитектурных подходов, которые расширяют границы платформы. Стратегии смягчения, определенные для каждого значительного риска. Работа прототипа или подтверждения концепции проверяет предположения для технических подходов с высоким риском до полного выполнения обязательства по созданию. |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Нет планирования | ⚠️ Избегайте начала сборки без анализа объемов данных, последствий ограничения управляющего или выбора схемы. Семинар по планированию архитектуры должен определить ключевые ограничения, выбрать схемы и проверить их по контролирующим ограничениям перед началом создания. |
| Недокументированные решения | ⚠️ Избегайте архитектурных решений, принимаемых на собраниях, не собирая контекст, обоснование, альтернативы и последствия. Используйте записи решений по архитектуре, сохраненные в управлении версиями, сохраняя контекст решений для будущих участников рабочей группы. |
| Нет анализа создания по сравнению с покупкой | ⚠️ Избегайте создания настраиваемых решений без оценки AppExchange. Оцените лучшие 3-5 актуальных пакетов перед настраиваемой разработкой. Сравните TCO, включительно с усилиями по внедрению, обслуживанием, стоимостью обновления и расходами на выход. |
| Недоработка | ⚠️ Избегайте создания только для текущих объемов данных без проекции роста. Рост данных проекта за 2-3 года. Создайте схемы запросов с выборкой, проверенной по 5-10-кратному текущему объему. Создание архитектурного запаса для роста. |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Управляемые пакеты второго поколения (2GP) | ✅ 2GP используется для новых управляемых пакетов, требующих изоляции пространства имен, распространения AppExchange и защиты IP-адресов. Бизнес-правило разработки на основе источников с разработкой модульного приложения. Зависимости пакета управляются явно. Версии, выпущенные с семантическим вариантом. |
| Разблокированные пакеты | ✅ Разблокированные пакеты, используемые для внутренних корпоративных приложений, требующих модульности без ограничений пространства имен. Независимое развертывание пакетов без зависимых от организации артефактов. Зависимости пакета отслеживаются для правильного порядка развертывания. Стратегия версии, определенная для внутренних пакетов. |
| Границы модуля | ✅ Четкие границы ответственности, определенные для каждого пакета. Каждый пакет несет ответственность за модель данных, бизнес-правила и автоматизацию. Пакеты взаимодействуют посредством определенных интерфейсов, а не прямого доступа к объектам. Документация определяет ответственность за пакет и межпакетные контракты. |