Selling DDD

A little while ago, we gave a series of short talks called “DDD Basics” for the Belgian Domain-driven design community. The focus was on strategic design. < shameless self promotion > I got some awesome feedback on my part: @ToJans @DDDBE I really loved your talk last night ?? — Tom Marien (@Tom_Marien) 12 februari 2014 @ToJans @DDDBE no remarks, it was perfect, inspiring and motivational — Tom Marien (@Tom_Marien) 12 februari 2014 </ shameless self promotion > My session was about selling DDD, and while the slides can’t show you how much interaction there was, they do contain the gist of the ideas, so I decided to post them to my blog anyway; enjoy them!

Why bad software architecture is easy to monetize

This morning I received yet another “interesting” job offer, which looked like this: Wanted: "senior .Net architect" Description "build one framework to build all future projects, using sharepoint" #ThanksButNoThanks — Tom Janssens (@ToJans) 17 februari 2014 Building a single framework to rule all your customers is just plain wrong. I did it in the past and now I know better. Why do a lot of consultancy/web shops do it then? Let me tell you a story … About someone building a house… The project You would like to build a house.

The very first #DDDBE event: the modellathon

This is my personal review of the @DDDBE inaugural meeting: a modellathon. Some background info So, last night we had the very first event of the Belgian DDD community: a modellathon facilitated by Mathias Verraes and Stijn Vannieuwenhuyse, and kindly hosted by the hosting company Combell. For the people who do not know the concept of a modellathon - in fact, I think we might even have invented the term maybe, but I am not quite sure -, it was something we spiked like a while a go, while coming back from the London DDD Exchange: As we were sitting together on the train with some of the #CQRSBeers guys, we considered starting a Belgian DDD community, and having real workshops.

My #CQRS cookbook

Here is my personal take on how I interpret all things CQRS… Commercial impact: why use CQRS ? CQRS enforces you to apply strict boundaries to your app in a consistent way. These boundaries convert your single application into 3 separate parts, only coupled by commands, events and queries. By using CQRS you convert your single app into 3 apps who can be built in parallel. So basically, when you do have enough resources, the approach can decrease your time to implement something by a factor of 2.5 (estimate, 3 times - 0.5 for the common interfaces - commands, events and queries).