(This is the first installment in a series of posts that will explain what we think is wrong with the current state of affairs in the mainstream business application development industry, and how we plan to fix it)
One term that often appears in a conversation between two developers deciding how to better write a piece of code is “separation of concerns”. But what is a concern and why is separating concerns so important? And even more, why is it being discussed here?
A concern is any basic responsibility a software system has to address. A software system has to deal with many different concerns as it bears many different responsibilities. Basically, a system is made of a collection of composition units or modules (functions, classes, methods, components etc) created to collectively address all of the different concerns imposed by requirements.
But every concern leaves its imprint on the system being developed, in the form of changes or additions to the code. The more places a concern leaves its imprint on, the harder it is to adapt the system due to a change in requirements. The reason is twofold: if the code dealing with a given concern is scattered throughout multiple modules, it is hard to figure out exactly what different places in the source code need to be changed; and if a typical module handles many different concerns at once, it is hard to tell apart code that deals with one concern from code that deals with another.
Point #1: the more independently concerns are dealt with, the easier it is to evolve the code when requirements change.
Ideally, every single concern should map to a single composition unit. If a concern ceases to exist, you delete the corresponding composition unit. If a new concern needs to be taken into account, you just create a new composition unit to deal with it, and no other part of the system is affected. But life is not pretty like that. In practice, there is actually a good deal of interaction between different concerns. So even though maintenance-wise it is better that different concerns are dealt with as independently as possible, it is still required for the system to run correctly that some level of coordination take place between parts of the code addressing different concerns.
Point #2: however, some sort of coordination between code dealing with different concerns is often required.
OK, so far it has been pretty much all common sense, as up to now, we were just trying to level the playing field. But one thing that is not quite common sense yet is the notion that every concern inhabits one of two completely orthogonal dimensions.
One of the dimensions, the dominating one, is home to concerns related to requirements originating from the problem domain. Let’s call it the problem domain dimension. These concerns can be completely understood and dealt with regardless the implementation language or target platform. The richer your problem domain is, the more concerns will inhabit the problem domain dimension.
The second dimension, which we like to call the implementation technology dimension, is also essential, but concerns in this dimension have more of an additive nature. Concerns in this dimension are originated from requirements related to the implementation space, and bear no relationship whatsoever to concepts in the problem domain.
(Are there more dimensions other than the two discussed here? Probably. But pragmatically, we believe that a clear distinction between problem domain and implementation related concerns goes a long way and is the first step we must take.)
Point #3: concerns inhabit one of two dimensions, either the problem domain dimension or the implementation technology dimension.
One important benefit of acknowledging this is that we can now understand that a dimension imposes a common set of characteristics to all concerns inhabiting it. That has several implications, from a much higher degree of reusability to interesting opportunities for work specialization.
But let’s leave that to the next installment. Meanwhile, feel free to comment or ask any questions, just as usual.