Saturday, July 5, 2014



Nancy.Linker is a small library for creating URIs for named routes in Nancy application that I released to NuGet the other day.

Purpose of Nancy.Linker

The problem Nancy.Linker solves is to allow your application code to create URIs pointing to endpoints in your Nancy application without hardcoding the URI. Instead you refer to the endpoint by its route name and provide values for whatever route parameters the route expects. The library then returns you a suitable System.Uri.


Let's consider a Nancy application with this module in it:

The module does nothing interesting, but bear with me. The thing to notice is that FooModule has all sorts of routes - a constant one, one with a simple parameter, one with a constraint on a parameter, one with a regex segment with a captured parameter, one with an optional parameter and one with a default value for an optional parameter. To read up on Nancy routing check out the docs.

Now let's assume another module needs to put links to endpoints in FooModule in its own response. It can do so by taking a dependency on IResoureLinker from Nancy.Linker and asking it to create the URIs:

which will produce a response containing a bunch of links back to the FooModule. For instance the call 

results in this string (assuming your application runs on

Getting Started

Just install Nancy.Linker from NuGet:

Nancy.Linker will take care of registering the IResourceLinker with your container, so modules can just go ahead a take a dependency on IResourceLinker.

Monday, June 9, 2014

Software Architecture Open Space 2014

The fourth annual Software Architecture Open Space Conference is taking shape. The date is set to October 2nd. The registration has opened. The venue is booked. The announcements and invitations are being sent out.

This years conference will follow the lead of last years conference and be a 1-day event in Copenhagen. The day will be all about in-depth discussions, sharing knowledge, learning together and making connections.The team behind the conference is also the same as the team last year: Jeppe Cramon, Jakob Bendsen, Nikola Schou and myself.
The one thing changed compared to last year is that the price has gone up. The event is still non-profit - just as it has always been - but it turned out we lost money last year, so this year the price has gone up some in the hope that we hit the zero.

As has been the case all the three previous years the day is centered around around a series of Open Space sessions. The Open Space format allows attendees to shape the conference to be about exactly the subjects they want: Anybody can propose a subject and anybody can contribute to the discussion around that subject. More than that actually. Not only can attendees participate. They are expected to do so. They are expected to share the knowledge they have, to actively take part in discussions, and to propose subjects. This format has worked very well the previous years. I have personally learned a whole lot as well as grown my network substantially at previous Software Architecture Open Space Conferences.

Hope to see you there! Now go register :)

Saturday, May 31, 2014

Breaking Domain Layer Dependency on Data Layer: Use Events for Writes

In this final part of my series (part I, II and III) on reversing the dependency from Domain Model to Data Access code found in many traditional layered code bases I will show how raising Domain Events when Domain Objects are updated can further decouple the Data Access component from the other components.


To recap the initial situation is this:

The two previous posts show how to reverse the dependency between Domain Model and Data Acces either by letting the Presentation Layer talk to the Data Access code or by invoking Dependency Inversion.

Leaking Data Access Concerns?
Reversing the depedency by letting the Presentation component depend directly on the Data Access component works, but leaves the responsibility of making the Data Access component save entities to the Presentaion component. E.g. in this snippet of Presentation Layer code there is a call to wishListRepository.Save(wishList);

This may seem innocent enough, but saving is not a presentation concern, which means presentation code should not be making that .Save call.

Reversing the depedency by Dependency Inversion also works and alleviates the Presentation code from calling .Save. On the other hand the Domain Model code has to make the Data Access code save entitites. Doing this without the compile time dependency pointing from Domain Model to Data Acces is achieved by introducing interfaces like this in the Domain Model:

Again this seems innocent enough, but what about the Save method? On the one hand it does not reveal anything in particular about the underlying Data Access code or database. On the other hand it does imply that WishList objects can be saved - presumably to a database of some kind. Furthermore the Domain Model has to decide when to call .Save, which is not really a Domain Model concern. The Domain Model should be responsible for the Domain logic. The 'what' and the 'how' of persistence is the responsiblity of the Data Access component. The 'when' of persistence is also the responsibility of the Data Access component in simple cases and of Infrastructure code in more complicated cases.

Domain Events Enable Further Decoupling
If the Presentation component is not to call .Save and the Domain Model is not to call .Save then what? -The Domain Model will raise events when Domain Objects are updated - as done at line 10 in this:

The actual saving of the WishList is done in an event handler, which can be something along the lines of - notice that this class is part of the Data Access component and uses the Domain Model:

Now neither the Domain Model or the Presentation component makes any decisions about what, how or when to persist. The Presentation layer only retrieves Domain Objects as needed and interacts with them. The Domain Model just implements the Domain Logic and raises events whenever there are state changes. It is the full responsibility of the Data Access component to handle the 'what', 'how', and 'when' of persistence.

A Caveat
It is not always good enough to simply persist state changes right away as Domain Events are raised. Sometimes a Unit Of Work is needed. In such cases the Domain Event handlers should not persist data directly, but rather interact with the Unit Of Work to record changes. Whether the Unit Of Work eventually ends up being commited or not is not the concern of the Domain Event handlers. They can rely on Infrastructure code to take care of persisting or discarding the changes recorded by the Unit of Work.

Simple Eventing
Implementing a simple mechanism for raising and handling Domain Events amounts to iterating over all Subscribers calling them one after another when a Domain Event is raised, and to register all Subscribers. That is having this:

and registering all Subscribers with that class in the Composistion Root. This can be done by explicitly listing all subscribers, by discovering them by scanning assemblies or in case the application uses a IoC/DI Container by asking the Container to resolve Subscribers.

Rasing Domain Events further decouples the Data Access component from the rest of the components. It frees other components of the responsibility of deciding what and when to save, and it allows both for simply saving immediately and for delegating to a Unit of Work.
Raising Domain Events also allows for similar deploupling of other components - e.g. integrations to third parties.