flxbl docs
slackGitHub
  • flxbl
  • sfp
  • sfops
  • Introduction
  • Minimal Framework
  • Who uses flxbl?
  • Learnings from the flxbl community
  • OVERVIEW
    • Principles
    • Modular Development Renaissance for Salesforce
    • Toolbox
  • TECHNIQUES
    • Development Practices
      • Why modular development in Salesforce?
      • Organizing your code / config
      • Defining the boundaries of a package
    • Source Code Management
      • Project Structure
      • Branching Model
      • Branching Conventions
      • Feature Toggling
      • Dealing with Org Specific Metadata
      • Handling Profiles
      • Tracking Manual Steps
    • Environment Management
      • Guiding Principles
      • Pooling Scratch Orgs
  • BUILD AUTOMATION
    • sfp
  • CI/CD
    • sfops
  • Libraries
    • sfdc-feature-management
    • sfdc-trigger-framework
    • nebula logger
  • tools
    • sfdmu
    • browserforce
    • pmd
Powered by GitBook
On this page
  1. TECHNIQUES
  2. Development Practices

Organizing your code / config

A flxbl project is all about ensuring your Salesforce Org is well modularized in terms of functionality, as well as the deployment of the modules utilizes various forms of package-based development options available within Salesforce.

Traversing the concept of packaging can be a daunting task. In our exuberance of adoption, we cannot lose sight of purpose and value. Packaging for sake of packaging is a path toward disaster; just a road trip to nowhere. You wind up with a lot of cost and lost time.

Pillars of a Package

There exist three pillars of a Package which include Encapsulation, High Cohesion and Reusability. These pillars define a package as an entity not reliant on the environment/Org it exists in; except for standard Salesforce components.

Encapsulation
Defines the bundling of data with the methods that operate on said data. Encapsulation is used to hide the values or state of a structured data object inside a package

High Cohesion

Defines how closely all the components in a package support a common purpose

Reusable

The package can be reused without consequences of the environment; morphing to each environment. Please note, if a package has a dependency, then one need to adhere to the guiding principles.

Last updated 10 months ago