Application Architecture

One thing that I’ve been trying to up my game with is architecture, like most things it’s never a one fits all solution, but I find it interesting never the less. As any developer that has delved into software architecture, they’d know that there’s never one right answer, but by following generally accepted practices, ideas & concepts, such as uncle bob’s ideas. One thing that I’ve seriously grown to love is his take on clean architecture, as a developer that has somewhat little experience in the game, I mean compared to some people that have been at this game for 20+ years, I’m still a toddler at best.

But having some valuable experience, working on an array of projects, some big, clunky & complex beyond belief through to small, clean & simple projects, it’s safe to say that the different styles & architectures need to be different, sure they can follow some of the similar ideas, but if you were to build a to do application so that there are more layers than what you can count, you’re just shooting yourself in the foot when there’s simply no need for such complexity. However, I’m not going to talk about architecture that lends itself well to really small & relatively simplistic applications, no. Instead I will be talking about applications that are very large and/or have a lot of logic in place, thus a lot of complexity in place. That’s where a lot of uncle bob’s ideas seriously come into play & work really damn well, e.g. by having business logic within your entities, it ensures that a single entity can never reach a state that results in a poor quality of data. This in turn saves you a lot of head aches, such as trying to make sense of incorrect, corrupt or invalid data, or worse yet, trying to build stored procedures around really low quality data.

By applying ideas like this, it also means that you’re reducing the need for duplicated code or business logic, don’t get me wrong, it’s almost impossible to ensure that no single line of code is ever the same throughout your entire code base, if you tried to do that, I think that’d be a waste of time in all honesty. I mean I’m talking down to the level where you’re checking to see if an object is null or something trivial like that, that would just be a task that’s borderline impossible for a large scale application.

Even to date, with all of the developer conferences around, it kinda surprises me how a lot of developers overlook areas like this, while I’m no SQL guru, just by having referential integrity in place, that alone can take you a long way, but even there, it’s actually quite surprising how many developers overlook areas like that. Let’s take a website as an example, if you wanted to start breaking down a website into raw SQL, you might start by doing something like looking at how a website is structured at a high level, so you might start with the website itself. A website can consist of many categories, each category may have many pages, every page may have many sections, etc. I’m pretty sure you’re starting to get an idea of where you can go with that, but to this day, it shocks me how many developers get that wrong.

Don’t get me wrong, if you’re working for a start up, to get the architecture absolutely bang on the mark, first try, that’s near impossible because the business requirements will change & grow as the business itself changes & grows. Not to mention that in all fairness to a lot of SME’s, they’re often faced with rushing to get an MVP in place & out the door ASAP so that they can get more people using their product(s). That makes sense & that’s what makes working in SME’s challenging at times, is trying to find the right balance between clean architecture from the ground up & trying to bash out the entire solution within a day. ⚖

At least with larger companies they typically tend to have the luxury to have some time allocated to planning & design in general. E.g. IMO you should always start with tinkering with the UI first, from a dev perspective, it just gives me a good understanding of how the application needs to behave, how the data can be structured, etc. Sure you could go the other end of the spectrum & start with working on the underlying data structure itself, either way does make sense, it’s just a personal preference to start with the UI, especially when there are little/no specifications or guidelines in place.

Regardless of what architecture you go with, you need to consider how you will need to refactor at some point, it’s practically impossible to prevent the need for some degree of refactoring. But at least if you start with something clean, simple & clear, you’re at least giving yourself a good place to start, at least when another developer comes along, they can pick up where you left of relatively well. I also find that by using a piping style approach to writing code, it also means that your code typically starts to read more like plain English rather than code.

Framework Freedom

In my experience, you should always implement your specific business logic in such a way that it’s totally isolated & separated from your framework(s) of choice. There was one instance that springs to mind quite quickly when a previous developer had coupled some code quite tightly with a specific framework & it was a nightmare to maintain for that specific reason. When we wanted to change the application server, again, because it was so tightly coupled, it wasn’t what I’d consider a pleasant experience, we managed to do it, but at the same time, it was quite annoying.

I’m sure at some point or another, every developer has been guilty of this, the reasons aside, I’m quite confident in saying that every developer at some stage has done this. I for one am no exception to that rule, in the past when building out the likes of an Angular application, I’ve found sources that tell me to rely heavily on the framework, whish is arguably good & bad. But having done that, I soon found that when it came to upgrading the version of Angular, it introduced a hell storm of breaking changes.

This very quickly drove home to me that I should try to separate the likes of state management & business logic out & away from the framework(s) of choice. It’s cool what some of these frameworks can do, but by relying so heavily on them, in my opinion, you’re taking some risk in doing so, because of the fact that at some point that framework will change, by investing this heavily into it, I just see it as asking for trouble. I know for a fact that this may not be seen as a popular opinion, especially among the front end community because time & time again, I’ve seen developers rant & rave about how you should leverage this library & this framework, etc.

Don’t get me wrong, it’s somewhat good to use these frameworks because of the fact that they’ve been through a lot of testing, there’s usually a lot of good documentation, etc. But there’s the trade off & obviously you need to consider whether it’s worth it for yourself & your team, e.g. if you’re working on a relatively small & simple microservice, then realistically it probably isn’t too big of a deal as to what framework you use, as long as the application works & it works well, that’s all that should really matter. But for the likes of a huge monolithic single page web application, then you should probably revise your architecture quite carefully. It’s quite funny, because I’ve not come across many front end applications that have been developed with good & solid architecture in mind, more often than not I’ve found that front end applications are usually rushed, as long as they work, no one cares, maintainability isn’t a major concern.

I’m not saying all of this to try & criticise anyone, it’s just the reality of the current development world, as I’ve stated, I’ve been just as guilty as anyone in the past. But moving forward, one thing that I will make a conscious effort to do is to really think about the architecture in future, try to completely isolate concerns & think of things from a business focused mindset.

Something like this springs to mind when I think of freeing myself from any framework! 😅 – But in all seriousness, I’ve been doing it in some cases where time isn’t such a huge constraint, I’ve been pushing myself to really think about the design & to really focus on ensuring that the code that makes up the business logic can easily be transported from one framework to another without having to worry about trying to wrestle the existing code base into an entirely new one.

Conclusion

Myself included, I think that more & more developers really need to start practicing good design, for the given context, e.g. it’d be pointless to build out a really sophisticated design for something incredibly simple, that’s just simply over-engineering there. But this is where the use of interfaces can be a god send, if you were to change something like your DAL, e.g. moving from SQL to NoSQL, provided you’ve got some extremely clean architecture in place, all that’d be really required is to change the part of your code base that’s responsible for the DAL layer, because that’d require a different driver to connect to the different data store. This is a primary example of where I’ve seen people trip up, they couple code far too closely to the underlying data store, to the point where trying to change the data store would practically justify a complete re-write of the entire application (the back end application at least anyways).