+972 52-548-6969
Architecture Advice: Scale the architecture to fit the application
I was just reviewing an application that was obviously built upon a lot of the best practices advice for using an NHibernate application. I am currently in the process of ripping apart much of that application and then putting it back together again.
This involve things like collapsing projects, removing abstractions and deleting tests. The main reason for that is quite simple, the architecture is too big for the application. We can create a much more stream lined application is we don't burden it with an architecture that is suitable for bigger and more complex applications.
Selecting an inappropriate architecture is a big burden on an application, and it is one where you should be very careful. Chose an overly simplistic architecture, and you can only scale the application complexity with great difficulty. Chose an overly complex architecture, and you can't even get the baseline working easily, because of the complexity involved.
Don't try to make an application fit the architecture, and don't try to apply architecture blindly. Think and always start from the simplest thing that can possibly work.
Comments
What about just using Evolutionary Design?
http://www.artima.com/intv/evolution.html
Frankly, I apply these ideas for many years with success.
It has always pissed me off when people seem to try to make something as complicated as possible, whether to show off their skills or just because they don't know any better. It can really be a major killer for projects. I think we should make a TV show and call it, "When Architects Go Bad".
I find that a lot of people do that, too. They pile on a lot of incidental complexity without even thinking about what they're actually doing with the code (e.g. adding a database call where it doesn't belong, or using a database when what's really called for is a simple XML file, etc.). Once the incidental complexity adds up to critical mass, that's it - the project is a wash. No one can debug it, and it's time for a rewrite with less complex pieces, in my opinion.
Yes, I hate it when that happens. When they tell you that in order to have a textbox in the UI have a maximum value you have to add that value to the database, the DAL, the data proxy, the entity, the business logic layer, the UI input data entity, the Service Interface and only then will you be able to access it - you know something is wrong.
And those variables always turn up as 0 in the first try because you forgot one of those pesky Entity1.Variable = Entity2.Variable lines.
Couldn't you write that six months ago ? ;)
This has bitten me in the rear more times than I count. Mainly because when I started developing I applied an Admin's mindset of "always being prepared" boyscout style to software development.
I had a couple of projects end up taking months longer than should have before I figured out I was doing something terribly wrong in my approach.
Even now, I have to constantly guard against trivially adding a "simple feature" that creates an unnecessary overhead, and have slipped in a bad decision here and there.
I think this is only something a lot of us can only develop with experience, repetition, observation and a lot of self-honesty.
These two statements seem to contradict:
"Chose an overly simplistic architecture, and you can only scale the application complexity with great difficulty."
"Think and always start from the simplest thing that can possibly work."
simplistic and simple are not the same thing
Comment preview