ELI5: What Are Architectural Patterns, Anyway?

ELI5

As I progress in my Salesforce architect career I come across increasingly complex concepts. Translating these topics into simple terms serves two purposes:

I learn more about them (as someone smart once said, if you can't explain something in simple terms, you don't understand it)
I give back to others who are also learning by making the complex more accessible.

So I'm going to write ELI5 posts every now and then, and if you'd like to see all of them, just click on the ELI5 tag. Here's the first of (hopefully) many - Architectural Patterns.

What Are Architectural Patterns

When you're designing a solution, there are some common, repeatable solutions you will find yourself using over and over. The architectural principles and structure behind these repeatable solutions are what's known as architectural patterns.

Commonly Used Architectural Patterns & Their Definitions

There are a few architectural patterns you've probably heard of before. Here's the ELI5 definition for some of them.

Event Driven Architecture

Put simply: when something happens, do something else. There are two parts to the Event Driven Architecture - the event itself, and the event message.

An Event is described as "a significant change in state". This could be a new record being created; a field being updated; a point in time being reached (e.g. 1 week prior to contract expiry date).

An Event Message is the notification that the event has happened. This could be published when the event occurs - in Salesforce terms, you might have an after-save Flow set up to trigger the creation of a Platform Event, or you might have Change Data Capture set up to publish events for an object. It could also be detected by some sort of monitoring system, for instance you could use an API to poll for changes to pick up information about an event, and generate an event notification.

An Event Channel is like a radio station - the place the event message is broadcast.

And finally you have Event Publishers and Event Subscribers which are self-explanatory.

Event driven architecture is an example of loosely-coupled architecture.

Event Driven Architecture

Layered Architecture

Salesforce Architects posted an article about architectural patterns - which is great, and gives you a good visualisation of the layers within Salesforce, but I'm going to be really honest here, it's pretty hard to digest. Sometimes, technical writing can be a bit like reading a different language. So check the article out but don't feel bad if you don't understand it all, I certainly don't!

Salesforce, like lots of other applications, is divided into multiple layers that can be interacted with by a person or another system. There are many names for the layers out there - and it doesn't really matter what the names you use are, just that you are separating them. The idea is that most of the time, each layer can only utilise the layer directly below it.

Going from top to bottom, here are some types of layers you might come across, and definitions:

Presentation Layer - the user interface - think Lightning Pages and page layouts that users interact with. This is where things like the Translation Workbench are applied.
Application Layer & Business Logic Layers - I'm merging these two for simplicity's sake, because both layers include config & code that you make to your own Salesforce org that control how business rules are programmed into Salesforce. This could be something like switching on Enhanced Email; building a workflow rule, process or flow, or apex trigger to handle automation; the licensing each user is set up with; and integrations to external systems.
Persistence Layer - the layer that controls making updates to your database layer. Think CRUD - you might create, read, update, or delete a record in Salesforce. This could be done by a person via the Presentation layer by clicking edit, making some changes, then clicking save. It could also be done automatically by the system as a result of an integration - say, an event is published by an external system, the Application/Business Logic Layer picks up this event, and makes changes to records in Salesforce as a result.
Data Layer - the actual storage of data goes here. You know how when you create a new field in Salesforce, it automatically creates an API name once you type in the label? Yeah. That API name is what Salesforce is looking for when you're interacting with the system in some way, and it's how to identify that unique field within the database layer.
Infrastructure Layer - this is where Salesforce does lots of the hard work for you, so you can focus on optimising the Salesforce platform for your own business. Think platform functionality like standard APIs, Salesforce Event Bus, orgs (production & sandbox), security framework, that kind of thing.

When someone is using your Salesforce org, they can't just dive straight into the database layer and start doing stuff. They have to come through the top layers - a person will start at the presentation layer and their updates will traverse through the lower layers into the database layer. A system might connect to Salesforce via an API, but it still needs to traverse through the business and persistence layers before any updates are made to your database.

Layered Architecture

Microservices Architecture

Microservices architecture is so hot right now. The idea is you break your application's functions and processes out into tiny, reusable microservices that you can call from lots of different places. It means you're only building / maintaining the service in one place, rather than having to build the same thing in many places.

You could implement a microservices style of architecture using Salesforce as the core system and call out to an external system like Heroku for repeatable external processing - something that would be pretty useful if you couldn't build that service within Salesforce without hitting governor limits.

Microservice architecture is an example of loosely-coupled architecture.

Microservices Architecture

Monolithic Architecture

You could call this one Architecture Classic, as compared to the cool and trendy Microservices Architecture. Monoliths are applications built on one, self-contained tech stack. It's a good name - monolith means composed all in one piece, and it also means too large and unable to be changed.

You might have also heard people talk about tightly-coupled architecture. That's what this is - everything needs to be in place for the application to work.

While it might be big and slower-moving it's also easier to test and debug, because there are fewer systems to connect together, where each connection is a potential failure point. It's great for simple apps, or apps that are starting simply - but once the app becomes complex, it's time to refactor to a different architectural pattern.

Monolithic Architecture

Summary

I hope this ELI5 has helped give you an understanding of some of the common architectural patterns you might see referenced. Have I missed any that you're keen to know more about? Have I confused you, or did I confuse myself and get something wrong? Tweet me! @heyemilyhay :)