How to properly decouple database layer from service layer in Apex?

Question

I came to Salesforce from the world of Java and have been working with Apex and Salesforce for a year now. I am constantly trying to implement Java (and OOP in general) programming practices in my daily development, but I cannot wrap my head around concept of declarative development. My latest opinion is that it is evil and no company that want stable working code should use it.

Consider such a problem:

• I have some Custom Objects A and B. I was asked to write an after insert trigger for A object that will create new B record with lookup on inserted A record.
• I implement such an behaviour but in few month some administrator add to the B new validation rule. He receive no warnings or notifications but as soon as someone insert new A record everything is crashing with hard error and they are calling me to fix the problem.

You can see few issues with this situation:

1. If admin need to click "Run all tests" every time he/she add new required fieldalidation ruleuilder flow what is the point for him/her adding this thing. He/She needs to call me for such tasks.
2. If he/she already called me for this task why would I make validation rule, if I would rather do it with code and cover it with tests properly.
3. If I do it with code, why would I do it in trigger - same error can appear for other developers. I would rather do it in Service Layer aka "before context hit the Database Layer".

So, in general I have such questions:
Is declarative programming creates more problems then solves?
If no, how should I write my code so I will not be distracted every time Admins in the PreProd org decide to change database model and\or validations?

Honestly, I am feeling like I am missing some obvious best practice that was taught to everyone else. I do not really know how enterprise orgs from big companies like CocaCola, or MasterCard are developed. They cannot have this problem and I am curious how they overcome this.

Answer 1

My latest opinion is that it is evil and no company that want stable working code should use it.

This is not true. Because you are coming from Java background, you can easily "code" and see similarity all around in Lightning/Force.com platform viz., classes, triggers, etc. as most of those derive their syntax, philosophy from Java. But consider small companies/non-profit orgs which cannot invest much, but still want to utilize the CRM space of Salesforce. That's where they can have anyone without any programming background to easily configure things. Declarative programming is one of the best features that Salesforce provides in such area.

Furthermore, for your questions:

Is declarative programming creates more problems then solves?

No. Part of it goes to the point as above. It all depends on which approach you want to take. Declarative approach sometimes saves you time and money. And there will be always mix and match of declarative vs. programming. But for an effective software delivery, you need to plan which approach you want to take based on your capacity. E.g., you can validate a field using a validation rule or in a trigger, so where do you want to do that. It's a design call.

If no, how should I write my code so I will not be distracted every time Admins in the PreProd org decide to change database model and\or validations?

Any software development cannot occur independently. There needs to be a governance to it and that it goes through a Change Management process. It's a coordinated activity and cannot be developed independently without crossing paths (you would have seen this in your Java world too, and its not different here). E.g., a developer A cannot keep on building things which will break things developed by developer B. For an effective development model, you should explore the options around source repository and integrate it with CI/CD (Continuous Integration and Continuous Delivery/Deployment). You should also write test classes effectively which will help you to identify any changes. Using CI here and following an effective Change Management and Governance will solve most of your problems here.

---

Here are few links which will help you to get a perspective around declarative programming in Salesforce:

• When to Use Declarative vs. Programmatic Tools to Create Salesforce Apps
• Develop Without Code

Answer 2

Is declarative programming creates more problems then solves?

Like any Java library or tool in general, improper application of the technology will create problems. Regarding workflow rules, validation rules and the like, why wouldn't you use a freely available library to speed up development? Declarative features are not the problem. The problem is usually in the process by which a team allows those features to be employed.

If no, how should I write my code so I will not be distracted every time Admins in the PreProd org decide to change database model and\or validations?

Since the problem is the process and not in the technical implementation, I do not believe there is any practical way to write code to both be meaningful and to be insulated against other changes by people who are able to affect system behavior within the same org. You could create your own library or standalone package, I suppose, but then you are now effectively a team of one who is unable to effectively collaborate with others.

Salesforce in 2018 is very different than it was 8 years ago when I first started working on the platform, and I recently published some thoughts about the evolving definition of an admin vs. a developer. The relevant point applied here is that only developers following well established source-driven development practices should be allowed to touch any feature that affects critical system behavior and UX.

In case it helps, below is an example of what admins should be allowed to manage vs. what developers should be asked to build.

An admin can manage the following in production, except for any items of that type that are tracked in the VCS.

• Assignment rules
• Queues
• User profile, role and permission set assignments
• Reports and dashboards
• List views
• Custom report types

All changes to the following require a developer on a development team to carefully build, unit-test and validate through a robust, version-controlled workflow.

• Objects and fields
• Page layouts
• Validation rules
• Workflow rules, Lightning processes, flows
• Role hierarchy
• Profiles and permission sets
• Apex and Lightning Components
• Third-party apps

You don't have to adopt these lines exactly. But I think your team should adopt some clear, unambiguous lines on who's allowed to do what where.