Arquitectura Apex para plataformas empresariales de Salesforce

Los orgs de Salesforce rara vez fallan por una sola clase mala. Fallan porque la lógica de negocio se acumula en triggers, flows y automatizaciones puntuales hasta que nadie puede predecir qué va a hacer la actualización de un solo registro.

El remedio es aburrido y efectivo: un trigger por objeto, un handler que solo enruta, y servicios de dominio que contienen las reglas reales. Una vez que la lógica vive en clases Apex simples e inyectables, se vuelve testeable sin tener que retorcer el conjunto de tests alrededor de la plataforma.

Los Lightning Web Components deben mantenerse livianos. Dar forma a los datos es responsabilidad de los controladores Apex con contratos explícitos, para que la UI pueda evolucionar sin arrastrar la lógica de queries.

Los governor limits son una restricción de arquitectura, no una molestia. Los patrones seguros para bulk, las queries selectivas y el procesamiento asíncrono deben decidirse en tiempo de diseño, especialmente en orgs que absorben múltiples marcas o adquisiciones.

Combiná todo esto con pipelines de deployment reales y tests de regresión. El porcentaje de cobertura es un mal objetivo por sí solo; el objetivo real es un conjunto de tests que detecte roturas de integración antes del release.