Salesforce DevOps | Author of "Clean Apex Code" | Product Manager and Software Engineer
What if you wrote most of your Apex code like this? This is pure business logic. There's no mention of queries, DML operations, bypass logic, governor limits and all that. This is as close as you can get to the actual business requirement: "When an opportunity is closed won, create a contract". You can test this code with pure unit testing. If most of your code was written like this, then most of your tests wouldn't even need to call the database. This is known as the "functional core". Of course, you have to wrap this code with "infrastructure logic", which actually takes care of querying, updating the database, etc. You can learn more about modelling business logic in Apex at awaf.dev
createContract method should create a contract, returning results not enough;) ClosedOpportunity as class name should also represent closed opportunity in some way.
Hi Pablo Gonzalez 🇨🇷 this is a really interesting approach! I noticed you’re using an enum in this example—just curious, is there a specific reason for choosing an enum over a simple boolean variable here? Would love to understand the design decision behind it.
It’s not business logic - it’s barely a business rule. No one will care about this part - that’s why it’s so easy to test. The relevant logic that anyone cares about is not the one-liner that makes the decision, but the „engine“ that executes this decision.
Thanks for sharing this Pablo. What are your thoughts on how to handle such a Decision? I've been playing around with an idea of launching a Platform Event around certain Core Business process stages and I can see how adding a Decision as what populates the event model would be useful - especially when paired with a Transactional Outbox or similar pattern.
The very first thing that is highlighted here is that a code should be easy to read. Now what does « easy to read » really mean? For sure it depends on who is reading… Also that approach would break the business versus technical people barriers Have you ever head: - business people saying it’s too technical they don’t know what the heck the dev team did in the app… - OR technical people saying that they implemented just a stupid business requirement which they don’t understand the value.
Salesforce Consulting Wisconsin Dev Center | Never Off Shored | Managed Services and Fractional Teams Starting $1,250 per Week
3dI'd rather have a CreateContractResponse class that has that decision property enum, but with maybe also some other related info like the recordId the response is related to.