Have come to feel very uneasy with the usual object orientation. It simply does not deliver on its promises. That´s of course not the fault of object oriented languages like C# or Java or C++. It´s the fault of those who use them in a way that leads their code straight into a brownfield. And it´s the fault of those who cannot provide easy enough guidance in using these languages.
The situation is very dire. I have seen only a very few developers who do not fear clean whiteboard. Because when they are asked to draw the design for a software they hardly know what to do. Where to start, what to do next, when and how to begin coding so that in the end an evolvable whole is created.
Class diagrams are definitly not enough as a design tool. Nor are three boxes stacked upon another labeled “Layered architecture”.
Also Domain Driven Design (DDD) falls short of providing true guidance. It is full of valuable abstractions and concepts – but how to apply them to a software design task at hand?
Maybe this is bullshit to you and you find software design just plain easy and straightforward. You deem UML and OOA/OOD enough. Your software is based on OO principles and is highly evolvable. Then I congratulate you and would like to know more about how you´re accomplishing this.
But maybe, just maybe my decription resonates with you because you too feel uneasy when it comes to software design (as opposed to software implemention aka coding). Then I´d like to invite you to follow along a series of articles I´m writing up in my architecture blog: http://geekswithblogs.net/theArchitectsNapkin.
Over the past months I´ve tried out a different way of designing software. A less object oriented one. One that´s less dependency focused, that does not need mock-frameworks for testing anymore. One that tries to deliver value to the customer right away. One that makes it easier to derive software architecture from requirements. One that makes AOP a first class citizen of any design. One that prepares designs for multi-core execution and distribution. And finally: One that keeps design and implementation in sync.
Sounds too good to be true? Well, see for yourself. It doesn´t cost you anything. Just hop over to The Architects Napkin – and suspend your disbelief for a couple of days while I´m writing up my current view of what I so far call Event-Based Components.
I´m looking forward to fruitful discussions with the community.