Software is often referred to as a living thing that changes and evolves over time. From the single-celled amoeba of a "Hello World" program, to the complexity of enterprise-level software, the range and variety in life occurs in software as well.
Complex organisms evolve systems for specialized purposes. Skeletons, muscles, and organs work as a discrete unit, but also interface with other systems to benefit the whole. The same is true of complex enterprise applications. By separating the various concerns into different systems, a healthier and more adaptable program evolves.
Complex code gets out of hand when you don't partition it properly. Code becomes heavily intermixed, making it error prone, difficult to maintain, and hard to learn, only serving to worsen the problem as you bring new developers into the party! Creating modules or libraries to share common calculations or processes among different parts of your application is often the first step in 'code re-use'. Which is of course, a very good thing!
If you're considering SOC properly, you're doing some upfront thinking about the internal plumbing of your application (down to class naming conventions and coding guidelines) that you feel will endure and hopefully be somewhat self-describing to others going forward. The usual adhoc approach to code re-use sees fragments of code getting moved around as soon as two or more areas start to need it. The code is often just placed in MyUtil classes or some other generic dumping area. Which is fine, and certainly recommended to copy-and-paste!
At a high level applications have three things: storage, logic and a means to interact with them (be that by humans and/or other applications). Once you separate these, you can start to define layers within your application, each with its own set of concerns and responsibilities to other layers, and the application as a whole. Careful consideration and management of such layers is important to adopting SOC.
On the Force.com platform, there are two distinct approaches to development, declarative (point-and-click) and traditional coding. Either can be used on its own or in conjunction. These two approaches fit into the standard SOC layers as depicted in the following image:
One of the key benefits of Force.com, is its declarative development model, the ability to create objects, fields, layouts, validation rules, workflows, formula fields etc without a single line of code. Declarative development is faster and easier, and already implements a degree of separation of concerns. So if your app is heavily data centric, you'll get by with delivering a large portion of your application this way!
So while not code, what you can achieve with declarative development is still very much an architecture layer in your application, one that I will talk about more later.
If your app is process-centric and/or getting pushed to implement more complex calculations, validations or richer UI experiences, you'll be dipping into the land of Apex code. Force.com provides many places to place Apex code: triggers, Visualforce controllers, APIs, batch Apex, email handlers, etc., the list goes on. You can make a huge investment in developing and testing code, but it's the business logic that you should be most concerned about protecting.
We will start to explore some rules for defining what goes into these in the further parts of this series. For now consider the following...
Depending on how you've placed your code, you may already be in good shape to tackle some of the above. If not, or just curious, hopefully the upcoming articles will help shed a bit of light for further thought.
This page is the first describing Enterprise Application Architecture patterns, particularly focused on applying them on the Force.com platform. If you attended Dreamforce 2012 this year, you may have caught a presentation on this topic. In the meantime, if you missed the session and fancy a preview of the patterns that help support SOC. You can find the Github repo here along with slides and a recording. For now, please feel free to comment, make suggestions and requests for topics and use cases you would like covered and I'll do my best to include and answer them!
The next article in the series can now be found here. Links to the rest of the series can be found in the Links section below.
Here are a few links to other resources, the DF12 session and discussions of late that relate to this post. These will give you some foresight into upcoming topics I'll be discussing here. Enjoy!