.NetAnti-patternsC#Client /serverDesign patternsDomain driven designFrameworksJavaService oriented architectureSmells of bad codeSoftware architecture

The merits of two-tier architecture. Domain driven development in the distributed era. Episode II

Go to episode one.

So now you’re stuck with this two-tier architecture. Is this a problem. Well, not yet. However, it can become a huge problem, and it has become a huge problem in many, many client / server applications, in a vide variety of technologies, including several types of (legacy) web application technologies.

The truth is out there

The problem with this architecture again is fairly simple. There is no single point of truth. Business logic is scattered. Consider this simple piece of business logic below.

if (StartDate < EndDate)
{
   ...
}

This code is now in the database, to keep the database from getting harmed. But it is also copied into one of the forms in the application, preferably on an event that is fired when the user tabs out of the field StartDate from, let’s say a Contract.

Eventually, there will be someone on the team of developers who is going to build another form that involves manipulating a Contract. It could be yourself, or any of the other well-educated developers, but there’s always someone how will copy-and-paste the business logic from the other form to the new one. And from that time on the truth is out there. Somewhere. After a while, you will end up with an application that looks like this.

image

And you might not even see that, because it happens over time. For instance, much of this copy-and-paste activity will take place after the application is deployed and it enters maintenance mode. Especially when the boys and girls doing the maintenance were not on the team that built the software.

Customers changing their minds

Still, this doesn’t have to be bad. It will become bad when something peculiar happens: the customer changes his mind on the business rule. Now, I know, that never happens on your projects, but on mine it did and it does. On average, requirements will change about 20% to 25% during the project. And there you go. Let’s say the customer just thought of the fact that the previous rule must be altered. Just a very small change, isn’t

if (StartDate <= EndDate)
{
...
}

So the boys and girls in the development or maintenance team start looking for the locations this business rule applies to. Of course, there is hardly any documentation, so they start searching the code. And you know what, they will find occurrences of the business rule and fix them. But, that’s Murphy for you, they will likely not find all the occurrences. The applications will now look like this.

image

And that’s where client / server fails. Miserably.