Software Engineering Essential Reading 2 - Domain Driven Design

In 2004 Eric Evans published his book “Domain Driven Design – Tackling complexity at the heart of software”. It's quite a heavy bit of literature, but every page is filled with insightful discussions of the benefits and practices on designing object oriented software with a model true to the business domain, and thereby worth every minute spent reading and reflecting. Eric has solid experience from developing software in support of complex business domains and he openly shares and discusses both success and failures.
The book discusses domain driven design (DDD) on several different levels:

• The importance to use the same domain model in all aspects of a project – in writing, in the spoken language and in the source code.
• The stereotyped building blocks used in modeling, design and implementation of domain centric software systems. Entity, Value Object, Repository, Service, Aggregate and a few more.
• How to use Strategic design and concepts such as Bounded Context to define current and future logical systems or enterprise wide architectures without having to unify the whole enterprise in a single domain model.

The book is the definitive starting point in learning and applying DDD, one of the really important design paradigms now and in the future. This book, together with the active community, both locally and on the Internet, has helped me in successfully designing and deliver complex software under complex technological and organizational circumstances. This is definitely one of the books I'm happy to come back to now and then and I think every professional software designer should have a copy. Before I first read it I was wondering why no one out in the “real” world used OO-design even remotely similar to what I learned and practiced in university. In his book Eric put this straight and he made me instantly feel “at home” with a true OO-design, carefully tuned to model the businesses, as the way to go about software design. Thanks Eric for sharing!

Value Producers and Supporters

In the lean and agile world anything that produces value for the client is a good thing, everything else should be carefully scrutinized before carried out. This doesn’t mean you shouldn’t produce any documentation, it just means you should produce only the documentation that someone is likely to read. It doesn't mean you shouldn't produce any automated tests, it just means you should make sure you produce them in such a way you optimize value during the development period and for future maintenance. To do this right you need to understand which part of the project organization is producing direct value for the client and which part is supporting the Value Producers.

In many projects you could find three groups of Value Producers: programmers who produce code that builds the product, testers who make sure the product does what it is supposed to do and technical writers who produce the user documentation. Everyone else, requirements analysts, architects, designers, etc, are usually in a supportive role. The Supporters does not themselves produce anything of direct value to the client, however that doesn’t mean that their work is not important. It is. As long as they make it easier for the Value Producers to do their work, now and in the future.

That said one of the challenges in running an efficient agile project is to understand who is supporting who and how to make it as easy as possible to produce maximized value for the client. In order to do that you first need to understand what deliverables (both artifacts and activities) that produce value to the client. In some projects the client might get great value from the structuring and questioning on  business processes done by the requirements analysts in order to define the system requirements. In other projects the client is perfectly clear on their business and the requirements specs are only needed to formally document the systems functionality and drive testing. Next you remove any activity or artifact that does not  add value to the client or is invaluable in order to support efficient value production and make sure everyone inside and outside of the project understands their role and for whom they are supposed to produce value, in other words: if  they are a Value Producer or a Supporter.