I think we all agree that our work is all about achieving high performance, scalable and most importantly simple solutions to complex problems. Over the years spent on developing and designing software solutions I have noticed the tendency to overcomplicate things by developers, DB architects and UI designers. After a certain time the reasons for that have eventually become clear to me. What I have observed is the fact that everyone focuses on their layer. They don’t pay enough attention to other parts of the system and don’t know how they could help their colleagues working on other layers.
In this article I will try to describe what I call the common sense development or the “Effect Driven Development” and provide you with my own formula for a happy marriage of the core parts of every system – the data layer, the business logic and the user interface. I assume that you understand DDD, CQRS, Onion Architecture and simple MV patterns so we will not focus on your business logic / services layer here. Instead I would like to focus on the equally important UI and the data layer.
Mr Data Base
I have been argued about this on few occasions but I still believe a good developer should know and understand the merits of a good data base design. There is too big a risk of making bad decisions while coding a well performing domain model without understanding how it will all eventually fit into the data store. Now, while data base is important there is also something else on the other side of the spectrum – your application front-end. The UI, which is nothing else but a graphical representation of this data store, grouped in sections (pages/domain objects). Given those two I really don’t think we can design one without deeply considering the other.
Miss UI
I have seen too many cases of the development being started from the business layer and I fully understand such an approach. After all BL is the challenging bit developers love the most and product owners see crucial to prove their idea can be materialized. So as developers we mock the DB and sometimes completely ignore the UI. What usually happens next is that when we get to the presentation layer we often realize that we have missed something, some connection. We notice misconceptions. And when we add the missing bits to make it all work we often realize that we should have structured the domain and by extension the data store a bit differently. So what do we do then? We try to come up with “fixes” since there is rarely time for a complete redesign once we have committed to the solution and time frame. When I say “fixes”, what I really mean is more or less nasty workarounds and hacks, which will hit our performance, code readability and often maintainability. I think we have all seen it on more than one occasion – the initial idea is rarely the best one… But what if we could greatly minimize this risk just by changing our mindset a little bit?
The Engagement Party
Why not focus on the happy couple in this marriage: Miss Presentation and Mister Data Store first? After all he provides the means to store the data which she presents to the world. Once those two are happily designed to complement each other, its time for children. The domain objects / services which will keep them happily glued together for the years to come. Obviously children are hard to raise but with the two happy parents there is little chance of something going wrong.
So, the way I see it, you should always start from interactive mocks of the UI, which allows you to achieve most or ideally all of the required functionality. Once completed and accepted by the client, think about each screen and design a data model which will be optimal and simple representation of this UI. In this way you cannot miss anything and you can be sure that all you can see, you can also create, load and update in the data store.
The real life scenarios where you hit the “data layer-presentation” marriage glitches often happen in more complex cases but I will give you a simple example of how things could go wrong if you didn’t follow the above UI->DB order:
The Marriage
Imagine your client asks you to develop an online music store in which he will be able to apply discounts on albums as well as single songs. So, you ask some follow up questions to make sure you have all the information required and then you dig right into creating an awesome business logic. In this logic, you assume each album and song will have a discount column. You successfully create the DB schema, some services and then UI to fulfil the requirement. And everything goes well until you find out at the mid development demonstration that the client would actually like to be able to create discount bundles with some nonstandard total price calculations.
At this stage the system is not flexible enough to painlessly add this kind of functionality. It could have been if you had shown its UI to the client first. It is unfortunately a pretty common thing for requirements to change after the product owner sees the initial work. What this means to you, though, is that you have to add a bundle and a discount table to the system and obviously remove the discount columns. So unfortunately a lot of work was unnecessary and if you had any unit test, you can pretty much scrap them too. Not a happy day for any developer, I would say.
The Honeymoon
To sum up, developing a mocked UI matching a data store may take some time but it is nothing compared to the refactoring time, the client’s dissatisfaction and performance losses you could be facing if you started with the business logic layer.
I assume that there are some of us lucky enough to have a brilliant data and solution architects in their team as well as a customer who provides clear and complete requirements. If you are one of them, I apologise for having wasted a few minutes of your time. But if you live in the real world where this is often not the case, please think about the above problems. Add some comments below if you have any thoughts of your own on this painful matter.