Building software is not a plug&play business as more than one might think, especially given the current circumstances of a world overwhelmed with modern technologies.

Everyday a new framework/library comes out and the market turns towards as if panacea found. We tend to think that new stuff mean the solutions to our problems.

It’s a philosophical issue, we reveal on it because, deep inside, we don’t feel ourselves complete and there is the lack of something we can never grasp. The same happens to new technologies, when they spring out we rapidly start wondering if the solution to our problems is on its way out of this.

But in professional grounds, just like in real life, there is no such a magic pill.

The untold story about Frameworks

At first blush, this repetitive emphasis on modern technologies and their downsides might be seen as sort of phobia to Frameworks but… nothing farthest from reality.

I do think frameworks are a great tool to make Software Industry’s Life easier, you see, not only developers life. But, things on its fair measurement because, at some point, platforms begin to represent an impediment to Good Software Design.

And this point reaches out the moment we tie our application so hard to the Framework that we mistake it with the Framework itself. We assume, from early stages in Software building, that the Framework is our very Application as if an eternal truth in stake; and, doing so, we sign a mortgage that we’ll never get free from unless we decide to tear the whole system down and start over again.

Coupling is the great obstacle arising out of this, and I think is the most important aspect to take into account when building applications because, it won’t let you migrate to better tools once you get married with a specific Framework, unless of course you decided to start over again from the ground up which is(almost always) from an enterprise standpoint not affordable.

The meat of this article

At this point, you reader, might be wondering what this has to do with the title of our article. Well, as I always remind on every post, this blog is more about philosophical than technical matters.

It turns out that the drunkenness of using it and becoming a Framework-Liever, I like the construction, blurs the reason against what really matters that is: Good Design. Of course this is a wide concept we need to land into proper grounds in order to start a discussion framework, so rapidly a good argument pops out, so the answer(at least one of then) to that question could be the purpose if this article.

In most of my circles these two concepts: Design Principles and Design Patterns are normally seen as ethereal and too much abstract issues that are not worth talking for and I think that somehow this is reasonable if we consider the fact that we, developers, are constantly playing ants following the dictations of Frameworks, and we don’t stop to think what lies beyond it.

I’m not talking about those technical details Frameworks abstract away in the quest of making our life easier so building high level solutions in the least of time. I’m trying to make this point: there is a common thread that is transversal to all Frameworks, moreover I could dare myself to tell it’s not intellectual property of any Technology. We’re talking about the Design Principles of Software Architecture.

Design Principles of Software Architecture.

There are hundreds of articles versing on this concept, so I won’t step into enumerating nor explaining them because there would be countless principles to walk down. I’d like to talk about the transcendence of these principles and the why: is not the same than Design Patterns. I find this quite attractive in the endeavor to make it more human hence not seen it as “God Almighty but never Seen” thus the reason of religious and atheists.

I’m not reinventing the wheel so I will quote Uncle Bob, the most entitled voice to talk about Clean Architecture which is, eventually, what this post is about.

Bob C. Martin, Uncle Bob for the most, postulates that a good Architecture must follow 5 great concerns:

• Independent of Frameworks.
• Testable.
• Independent of UIs.
• Independent of Persistence.
• Independent of any external agency.

Every high level solution, the grounds I swim at are Domain Specific ones hence I separate this concern, must be consistent with the aforementioned elements, is a rule of dumb the attachment to them.

He bases every Software Architecture to these 5 pristine aspects and based upon them he compiled the well known S.O.L.I.D principles which constitute the Bible of Clean Architecture. Like I said before, is out of the scope of this article to dive into these principles, but I must say is mandatory for all programmers to know and apply them.

Of course there are more Principles when it comes to Software Design but the link that brings them together is Separation of Concerns, this is like we say in Spain, La Madre del Cordero(lamb’s mother), this one states that we must separate the logical description of our Domain from those concrete details of implementation. This is simple and powerful, so coming to grips of it will automatically open the doors to Clean Architecture, from that moment onward the world won’t be the same any more.

Modern Frameworks, especially Web based ones, perform a shy attempt to cover somehow this Principle, but in my own humble opinion they get half way through on this journey. M.V.C and all its variations is a good example of it, but never enough because they don’t deepen sufficiently on the Foundations we are discussing here. And I think this is where developers fail, we assume the Framework does this hard work for us when is just the opposite, the nasty job must be left(actually what happens) to developers since is not the concern of the Framework to lead them towards proper Good Design decisions.

Incorporating Separation of Concerns into your values system flattens the path towards becoming a decent Software Designer. Everything is under inspection and you stop thinking locally to approach things globally. This principle infiltrates all aspects of Development Process, there’s some sort of autopilot that switches on and it’s always assessing things up in order to accomplish the 5 Design Principles.

We could say these principles are inherent to any O.O Architecture or High Level solution, they can and should be applied in any Design regardless the Business Domain being modeled. Every piece or component specially in O.O.D must be in alignment with Design Principles for the sake of Scalability, Maintainability and Testability.

The Design Patterns

Design patterns is different from Design Principles, and, as I have seen around in many posts and articles, very often, authors mix-up these two terms that actually are quite different from each other.

Design Principles are the Basic Laws of God, just like 10 commandments are, every high level software should be compliant with such Design Principles, is like a series of rules to follow in order to consider it a good piece of Software. This compliance is seen as a result, not a goal but a result; if you stare at Software from a Designer standpoint, the high level picture of the Solution will tell you whether Design Principles are accomplished or not.

Well, Design Patterns are a collection of techniques that are applied to specific scenarios in Software Development, there’s no obligation on implementing it, but they are way useful when modelling a specific Domain, especially rich Domains.

These patterns are typical of Object Oriented Design, but they could be applied to other programming grounds like functional programming for example. The concept was introduced and compiled by four authors that published a book named Design Patterns – Elements of Reusable Object-Oriented Software, these guys are well known in the circles as Gang of Four(G.O.F)

There are three main categories to these patterns: creational, structural and behavioral. This is, of course, a way of separating concerns so creating an object should be independent from its structure the same way the relationships between objects should be something addressed separately from the first two concerns.

The design patterns has more to do with gearing architectural modules within a specific business model, the same patterns are not applied across different solutions so as we can see there is no transversality in Design Patterns, they may or may not be applied and its mandatory character is not subject to a Good Design unlike Design Principles though is valid to mention the fact that using it eases the path to a good and more robust Design, it’s like a shortcut to goodness.

Epilogue

I’m not an expert in any of the subjects but I put an emphasis on trying to build well designed pieces of Software that’s why I felt the necessity of writing this post to open a window of opinions cause i’d love more persons start using these two concepts that entails a tremendous importance to Software Development.

I’d be glad to hear opinions as well as corrections, amendments and contributions to his thread.