Back in the days of client/server. Domain driven development in the distributed era. Episode I

At this point in time, where we slowly shift from service orientation to cloud computing, building business software is more complicated then it has ever been. There are many platform that your software needs to target, and there are even more ways of writing the software.

Beyond choosing technology

Choosing a technology goes way beyond stating that you are doing Java, .Net or Adobe, and can be quite complicated. A vast amount of architectures, patterns, frameworks – open source and vendor specific – is available to make life easier, but choosing more complex. With this paper – in episodes – I will try to make a point for building software around its domain, also in applications that consume services in a distributed environment. Especially in such a service oriented environment, since there is a wide variety of sources your domain can be fed from, including database, ERP, web services and the cloud – where ever that leads us to. In the sequential episodes of this paper, I aim at presenting a collection of patterns that will help you leverage your domain driven design independent of the back ends this domain needs to interact with.

Back in the good old days

But first things first. Back in the old days of client/server life was fairly simple. You could find the a way to get the data you needed from the database, usually using ODBC, and splash that data to a form, usually a Windows form. You could build applications in a jiffy. Didn’t we all love PowerBuilder, SQL:Windows and Visual Basic?

Then life got a little more complicated at the time the customer wanted some validation in the application. Let’s say hew wanted to make sure that the end date of a contract was either blank or later in time than the starting date. Here’s where the discussion started. The developers that previously worked with Clipper or DBase would insist to put this validation in the database. And they did. Nice and safe. The younger developers, including me, however would mention that if validation was delayed until the data reached the database, it was fairly late. Couldn’t we just build the validation into the form? Well, yes we could. And we did. So we ended up with a simple architecture, as shown below.

The nasty thing about this architecture is that both arguments hold. Yes, validations in the database is fairly safe. And yes, validating until the data is in the database is fairly late. So now we keep two versions of our little validation rule. One in the database, and one in our form. It’s the same rule. For now.