Whitewashing is the blog of Benjamin Eberlei and covers topics in software-development and object-oriented-design. Benjamin works for Qafoo and you can book him for consulting and trainings.
tl;dr Version: I present a list of problems with OOP business applications from my personal experience and then introduce 3 approaches that I was put in contact with over the last year, DCI, EBI and CQRS. This post is an introduction to a series about this approaches.
I mentally divide the world of programming into two large parts:
The first produces code solving technical problems, often in a beautiful and dedicated way. The second regularly produces mess, hopefully still serving customers by optimizing their business. This differentiation is an exaggeration, but from my experience its far easier to run a greenfield business project into the ground than a new library.
There has to be a reason why so many programmers dedicate much free time to open source projects. It might be empirical prove, that all our business projects don’t make us happy at the end of the day and we have to show ourselves that we can do better.
I enjoy writing business applications more than libraries, but they are also much more difficult to get right in both social and technical dimensions. One motivational driver of my open source activities always was to simplify the technical dimension of OOP business applications.
This blog post is not about blaming customers (as the usual suspect), its about finding the problems in usual OOP code of business systems from my experience with PHP projects. To keep things short, I will list my personal list of technical annoyances in business projects in no particular order. These are highly subjective points.
Essentially if you work in a tight schedule, project based environment where the decision makers sell rapid application development and prototyping, then you often have only one, maybe one and a half attempts to get the big picture right. From that moment on you have to build on that decision and hope for the best.
We have tried not to go the RAD+CRUD tools ways in several projects, to escape the problems listed above. But without changes in your mindest you end up with hand written mess, compared to getting there with tools.
Specifically Domain Driven Design applied naively can make the problem even worse. It easily leads to lasagna code, where you have layers of layers that are very hard to understand. Personally I prefer spaghetti code over lasagna code, because its comparatively simpler to understand.
Rather than to embrace the suck and dive deeper into CRUD architectures, I felt there has to be some solution to organize business models structurally to avoid all (or most) of these problems. In the PHP world with Symfony2 and Doctrine2 you have a powerful toolbox to avoid many of the problems above, but it is still not simple to write clean object oriented applications.
After years of participation in both open source projects I still feel there is a missing puzzle piece, to reach a clean separation of all the model concerns from framework and persistence.
At some point I would really like to close the gap between desired technical state of a project and the state it is actually in. I know there is no size fits all solution, but I fell a checklist of architectural patterns with pro and con arguments allows me to adjust the expectations about how a system looks in the end.
They are not new and have all been around for several years already. I would describe all three of them as architectural design patterns, though some people might probably disagree with this classification. All three approaches make you think about application development beyond just “service layers” in radically new ways. All three have helped me rethink business applications in different ways.
In the next weeks I will talk about each of these approaches individually, show some examples and then wrap up my thoughts about all of them.
Gordon and I will talk about this topic on the Free and Open Source Conference in Sankt Augustin Germany on 25th/26th August of 2012. Feel free to drop by and discuss this topic!