should SOLID principles be followed for business specific development?

134 views Asked by At

I'm developping a business specific application and since 3 months, I read a lot of articles about SOLID php development. I really think these guidelines can add high value to code and I would like to start respecting them in future works. But I'm really sceptical about SOLID dev in business specific applications, because I can't find any way to implement it in our current code. My project isn't going to be shared publically because it serves a really business-oriented purpose. As said, I read a lot of SOLID articles, but those articles give Book implementing Printable interface or Car abtracting Vehicle parent class as example. Those examples are really far from real-world applications. Real-world business-oriented applications are not dealing with books or cars, they are dealing with customers, products, orders, invoices, statistics, mails.

I'd like to start using interfaces for example, but I can't find in our project 2 classes with something in common/serving a similar goal which could take benefits of implementing an interface.

So my question is kinda simple, can SOLID development be applied and add value on every single application (and in that case, I just didn't find yet how to implement it on our project), or is this some kind of guidelines made for public development meant to be share ?

note: don't know if stackoverflow is the right site to post that, couldn't find any better stackexchange site related to this question.

1

There are 1 answers

0
plalx On

SOLID is pretty much synonym of good OO (there's obviously more than SOLID, but it's a great foundation).

What you are asking is basically: "can best practices be followed in real-word systems?" The answer is obviously yes! However, it requires a lot of practice and experience in order to apply those practices properly.

SOLID are principles that emerged from the industry after years of real-world application crafting and aims at making systems code base supple.

At first, you may not see many opportunities to apply the principles, but that would be because you have yet to identify the problems before applying a solution and that is much harder because modeling issues can be subtle at first, until they bite you.

"Our main problem is the database architecture which is very old and very badly designed. We are working on improving it, and that's why i read a lot about SOLID during the last months."

SOLID is mainly about OO and good OO modeling shouldn't care about persistence. If you want to improve your database architecture then you are looking in the wrong direction.

Instead of only focusing on SOLID, I strongly advise you to read about Domain-Driven Design (DDD). DDD is all about crafting domain-specific models in a way that is truthful to the domain and it's real-world aspects. The main essence of DDD doesn't lie in it's tactical patterns, but these are based on SOLID.