“The value of another’s experience is to give us hope, not to tell us how or whether to proceed.”
— Peter Block (through Woody Zuill in his talk on mob programming.)
Story time!…
During college, I became interested about solving algorithmic problems. But because of lack of mentorship and my lack of knowledge in higher maths and algorithms, I decided to concentrate my energies into studying how to create line-of-business (LOB) applications (or what is called “representational-transactional systems” here).
I thought to myself that creating LOB applications is much easier to do — it does not require lots of knowledge in maths — and I thought that I can easily get jobs in the future if I concentrate on creating LOB apps rather than solving algorithmic problems.
During those times, I was curious about how people structure their code in real-world projects.
I found out about this 3-Layers Architecture thing: you have a Presentation Layer, Business Logic Layer (BLL), and Data Access Layer (DAL).
I understood what a Data Access Layer is… because during college, everybody knows about databases — we were kind of brainwashed 
into thinking that the database is the center of our application. Creating relational data models was the first thing we do when creating software projects during those times.
Also, I understood what a Presentation Layer is — it has something to do with the UI.
But, “what is this business logic thing??”…
“Hmmm…“
I did not yet understand what it was during that time.
I also learned that if the app is very simple, one can choose to have two layers only: a Data Layer and an Application Layer.
This 2-Layers thing is much easier to comprehend! I know what a Data Layer is… “Anything that does not involve SQL must be part of the Application Layer!!”
Great!
So I followed this 2-Layers model in my projects during that time.
A few years later, I learned more about the Business Logic Layer and I came to understand that the validation of user inputs is part of the Business Logic Layer. So I used that knowledge in one project. I created a separate module for the BLL and then placed my input validations in there.
That was my first experience on separating the business rules from the other parts of a software system.
Then the web happened!… I mean, I realized that I need to know how to create web applications.
I started thinking in monoliths again because my attention was diverted into learning web frameworks (and later on, learning all these JavaScript libraries which pop from everywhere every millisecond of the day.
Luckily I found a job. And after a few months in that job, DDD was introduced to us, the junior developers. Our employer gave us some articles to read about DDD becase we will be involved in an in-house project where concepts from DDD will be used.
This experience gave me another thing to google for when deciding on how to structure my projects — “How do I structure a DDD prroject?”
Then… came… Uncle Bob Martin… with his charismatic presentations of Clean Architecture! He suggests (preaches even) that we keep our business rules separate from the UI, from the database, from the web! And he gave a sample diagram on how to do it. (You can know more about this diagram in the links I will give below.)
This is what I consider my enlightnment on how to structure software projects so that they will be maintainable — in my understanding, you just make sure that the business rules do not rely on things it should not rely on, such as the I/O devices… that’s it.
Whew!
Okay… End of story.
That was just a very long introduction to the following list of materials and quotes from our masters, which emphasizes the importance of separating the business rules from the other parts of a software system so that they will be maintainable:
Some great materials about separating the business rules from the other parts of the application
1. “A Little Architecture” of Uncle Bob Martin
“The business rules should not know what specific database you are using.”
Uncle Bob gives here an example on how to decouple the business rules from Input/Output things, such as the database.
2. “Clean Architecture” of Uncle Bob Martin
“No matter how large any one part of the system is, the other parts should be decoupled from it.”
3. “The Clean Architecture” of Uncle Bob Martin
“The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle.”
4. “Agility and Architecture” (OOP 2015 Keynote) of Uncle Bob Martin
“The web is not an architecture. The web is an I/O device. And we learned many years ago that we want to be independent of I/O devices”
“The database is not the center of our system. Our application should rule the database… The database is also an I/O device; something we want to be independent of.”
Uncle Bob has lots of other talks such as “Architecture: The Lost Years”. Google for them.
5. “Policy, Mechanism, And The Preservation Of Business Value” of Eddie Bush
“The business value in our applications is represented by the policy [or business rules]. Policy may change over time, and new policies may be introduced, but — if separation of policy and mechanism is followed faithfully — its value can be longer lasting than any user interface or persistence mechanism ever thought about.”
“Let’s face it, developers want to work on contemporary technologies. If you’re not separating policy and mechanism, it’s inevitable that you will find yourself in a less favorable position when it comes to recruiting top talent.”
“Don’t Ignore Simple Applications
“Simple applications are the first place you should begin practicing the separation of policy and mechanism because they’re simple. Once they have that formality applied, they can be great testbeds for new UI and persistence frameworks.”
6. “This Is How We Do It” of Terence McGhee
“One of the most important things that you can learn from me or from anyone else regarding professional software creation, is that you must build your systems for easy maintainability.”
And separating the business rules from the other parts of a software system is very important to achieve maintainability.
7. “Codesmith’s Delight” of Terence McGhee
“The primary value of software is that it not only meets today’s needs for today’s users, but that it can continue to meet the future needs of all of its users.”
8. “Reasons For Isolation” of Mark Seeman
He listed here three reasons why we should separate things that need to be separated in our software systems.
9. “Is Layering Worth the Mapping?” of Mark Seeman
Mark Seemann gives here an example of how to separate things in a software system.
He also said that separation is an “all-or-nothing proposition”
“… the point of the post is that as soon as you soften separation of concerns just a bit, it becomes impossible to maintain that separation. It’s an all-or-nothing proposition. Either you maintain strict separation, or you’d be building a monolithic application whether you know it or not.”
10. “Hexagonal != Layers” of Thomas Pierrain
Created by Alistair Cockburn in the 2000s, the hexagonal architecture was designed to prevent the infiltration of the business logic into the UI code (such infiltration leading to less testable and more difficult to maintain apps).
The proposed solution is to divide our software in 2 distinct regions:
the inside (i.e. the business application logic) and the outside (i.e. the infrastructure code like the APIs, the SPIs, the databases, etc.).
And remember what Eddie Bush said above: “Don’t Ignore Simple Applications… Simple applications are the first place you should begin practicing…“
Happy coding!!!
