Search This Blog

Monday, January 20, 2014

Show me the code

I finished Chapter 8 on Domain Events and Chapter 9 on Modules of Implementing Domain Driven Design. I liked the author's explanation of how to integrate two different bounded contexts using events. He gave a couple different options like setting up a REST feed of events and also using a third party messaging tool. I thought both examples were clear and easy to follow.

He also mentioned you could use events to hook your domain to your application layer and also use events to hook up different components within your domain. He gave an example he called contrived for hooking the domain to the application layer. It was basically a method on an aggregate that did nothing but raise an event which was caught by an application service that added something to a repository. It wasn't very helpful to understanding the concept he was trying to explain. Also there were no examples of how to use events inside your domain model. I thought I might get more information by downloading his source code, but I checked the java and .net versions and their were no examples there either.

I am also reading the Big Nerd Ranch iOS book. I was struck the other day by the difference in the author's styles. In IDD the author starts with a lot of details about what he is trying to explain then sometimes follows that with a snippet of code that may or may not help explain his theory. By contrast the Big Nerd Ranch book starts out with a bunch of code that you can compile and run. The Big Nerd Ranch author warns you that you probably won't understand what you are typing but urges you to type it anyway. Once you have a working example they then go back and explain what you typed. I like the Big Nerd Ranch style much better. I can digest the theory a lot better if I can look at the actual code. I think in some ways I read code better than I read English.

The modules chapter was pretty thin. The one thing I got excited about was when he said not to create a separate folder for each component like factories, repositories, value objects, etc ... We have this Services folder that I don't like because it groups all these random services together that are in no way related. Later in the chapter he did say you could have a separate model and services folder if you treat your services like a thin layer between the domain and application. I am guessing though he still wouldn't recommend dumping all the services in there. Instead you still need to break that folder up into submodules if you have more than handful of services.

Thursday, January 2, 2014

Wired review of a treadmill desk

I really want to try this:


Pair programming would definitely not work unless they make tandem models. :)