E-Book, Englisch, 206 Seiten
Malmqvist Salesforce Anti-Patterns
1. Auflage 2024
ISBN: 978-1-80324-799-1
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection
Create powerful Salesforce architectures by learning from common mistakes made on the platform
E-Book, Englisch, 206 Seiten
ISBN: 978-1-80324-799-1
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection
Salesforce Anti-Patterns teaches you to spot errors in Salesforce patterns that may seem like a good idea at first but end up costing you dearly. This book will enable Salesforce developers and architects to understand how ingenious Salesforce architectures can be created by studying anti-patterns and solutions to problems that can later lead to serious implementation issues. While there are several books on the market that start with the question, 'How do I create great Salesforce architecture?' and proceed to a solution from there, this book instead starts by asking, 'What tends to go wrong with Salesforce architectures?' and proceeds to a solution from there.
In this book, you'll find out how to identify and mitigate anti-patterns in the technical domains of system architecture, data architecture, and security architecture, along with anti-patterns in the functional domain of solution architecture as well as for integration architecture. You'll also learn about common anti-patterns affecting your Salesforce development process and governance and, finally, how to spot common problems in how architects communicate their solutions.
By the end of this Salesforce book, you'll have gained the confidence to architect and communicate solutions on the Salesforce platform while dodging common mistakes.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
Table of Contents - Why You Need to Understand Salesforce Anti-Patterns
- How Not to Mess Up Your System Architecture
- How Not to Get Confused about Security
- What Not to Do about Data?
- Unpicking Solution Architecture Troubles
- Keeping Integration Straight
- Keeping the Development Life Cycle from Going off Track
- Communication without Mistranslation
- Conclusion
1
Why You Need to Understand Salesforce Anti-Patterns
Salesforce anti-patterns tell us about the kinds of systematic mistakes that make their way into many Salesforce projects, mistakes that can even seem like a good idea at the time of implementation but end up having serious drawbacks in the long run. We will learn the most common of these mistakes and how to think about them throughout this book. However, to do so, we must first really understand what anti-patterns are and how understanding them can help us architect and design better systems.
In consequence, this chapter will start by explaining what anti-patterns are by going through a number of different definitions and ways of looking at them. You will then learn how they can help you deepen your understanding of architecture by knowing how these common mistakes are made and how they can seem like a good idea at the time. We then finish the chapter by explaining the book and the ways in which you can approach the content.
In this chapter, we’re going to cover the following main topics:
- Understanding anti-patterns
- Where do anti-patterns come from?
- How can anti-patterns deepen your architecture skills?
- Learning about anti-patterns from an example
Understanding anti-patterns
Most developers and architects will be familiar with the concept of a pattern – a good solution to a recurring problem within an architectural domain described in a formalized and reusable way. Some classic examples include the following:
- Singleton: A software design pattern that limits the number of instances of a given type to one.
- Fire-and-forget: An asynchronous integration pattern that sends off a message from a computational context and proceeds without waiting for a response.
- Model-View-Controller (MVC): An architectural pattern that divides an application into three tiers with specifically defined responsibilities:
- First, a model maintains the state of the application and is responsible for any changes to data
- Second, a view shows a particular representation of that model to an end user via some interface
- Third, a controller implements the business logic that responds to events in the user interface or changes in the model and does the necessary mediation between the view and the model
This pattern is shown in the following diagram:
Figure 1.1 – MVC pattern diagram
Patterns such as these have been defined at many levels of abstraction and for many different platforms.
References
You can look at the following resources to get a good introduction to the various patterns that one can apply from a Salesforce perspective.
The integration patterns guide lists all the main patterns to use when designing Salesforce integrations: https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro_overview.htm. In a Salesforce world, this may be the most commonly referenced set of patterns as they are ubiquitous for integration design.
The book from Packt, by Anshul Verma and Jitendra Zaa, provides patterns at the software design level and the concrete code level for the Apex language.
The Salesforce Architects site, while new, contains a range of patterns across domains, from code-level specifics to reference architectures and solution kits to good patterns for selecting governance: https://architect.salesforce.com/design/#design-patterns.
The point is that we have lots of good patterns to choose from on the Salesforce platform, many that are provided by Salesforce themselves, others by the wider community. Many patterns that apply to other platforms are also relevant to us and we learn much by studying them.
But this is a book about anti-patterns, not patterns. So why am I starting with a discussion about patterns? It turns out that the two are nearly inseparable and originate in the same tradition. Understanding anti-patterns, therefore, begins with an understanding of what a pattern is. Indeed, one common form of anti-patterns is a that has been misapplied. We will explore this in the next section.
From pattern to anti-pattern
The design pattern movement in software architecture originates from the work of Christopher Alexander, an architect whose job was to design buildings rather than systems. In his work , he introduced a pattern template for physical architecture that consisted of a name, a problem statement, and a solution in a standardized format.
The rhetorical structure provided by the Alexandrian template was rapidly adopted by architects of a different kind, the ones that build software. They recognized the power of a standardized way to describe problem-solution sets for communicating good practice. With the publication of the classic Gang of Four book, , the use of patterns became mainstream within software development and remains so to this day.
The research on patterns inspired an incipient community of practitioners and researchers in software engineering to think about failure modes of software systems analogously to how design patterns were being used. This happened over an extended period of time, and it isn’t possible to point to anyone in the anti-patterns movement that can be seen as the genuinely foundational figure.
However, many research papers on the topic start with the definition given by Andrew Koening in the Journal of Object-Oriented Programming in 1995. This definition says that an anti-pattern is very similar to a pattern and can be confused for one. However, using it does not lead to a solution, but instead has negative consequences.
That definition captures much of the essence and can be usefully combined with the following thoughts from Jim Coplien, another early pioneer. He thought that good patterns in and of themselves were not sufficient to define a successful system. You also have to be able to show that anti-patterns are absent.
In a nutshell, then, an anti-pattern is a pattern that occurs in unsuccessful software systems or projects that can look superficially like a good solution but in practice gets you into trouble. Some common anti-patterns that have been around for ages and are still relevant include the following:
- Stovepipe: A system or module that is effectively impossible to change because of how its interfaces are designed. See the following diagram for an illustration:
Figure 1.2 – The Stovepipe anti-pattern
- Blob: A design where a single class effectively encapsulates all the business logic and functionality, leading to major maintenance headaches.
- Intensive coupling: A design that uses an excessively large number of methods from another class or module in implementing a feature, leading to a deep dependency that is hard to understand or change.
We’ll dig into all these anti-patterns from a Salesforce perspective in later chapters, underscoring the unfortunate fact that Salesforce, while a great platform, is still a software system prone to the kind of mistakes that have plagued software systems for decades. If this were not the case, then, of course, there’d be no need for this book or, for that matter, for Salesforce architects.
Having discussed the historical origins of anti-patterns, we will now discuss how they arise in the real world.
Where do anti-patterns come from?
Anti-patterns tend to arise again and again because the circumstances that drive technology projects into trouble are at least somewhat predictable. Equally predictable are the responses of people put into those situations and as people in tough spots frequently make the same bad decisions, we get systematic patterns to study.
Generally speaking, the most important thing to remember about anti-patterns is that they seem like a good idea at the time. They aren’t simply bad practices that someone should know better than to apply. You can make a reasoned argument that they should lead to good or at least acceptable outcomes when applied.
Sometimes the decision to apply an anti-pattern is down to inexperience, and sometimes it is down to desperation. But as often as not, it is down to experienced professionals convincing themselves that in this case, doing what they’re doing is actually the right call or that this situation really is different.
We will try to reflect this diversity of origins in the examples we show throughout this book. However, to do this, we first need to show how we will present the examples in a consistent way to enable learning.
An anti-pattern template
One of the key characteristics of both patterns and anti-patterns is that they are written using a recognizable template. Many templates have been suggested over the course of the years, some more elaborate than others.
The template we will use in this book contains the bare bones that recur in nearly all existing anti-pattern templates. However, we do not include a great number of optional elements. Most additional...
