February 2011 Blog Posts
Index Part 0 – Introduction Part 1 – Persistence Part 2 - Domain Events There are many advantages to building a full domain model. However it is not immediately obvious how business logic inside classes mapped using an ORM can invoke behaviours outside the domain. Invoking services directly involves tight coupling and is difficult to test. Doing dependency injection into domain classes is problematic as they are controlled by another container (the ORM). As with so many things...
Some time ago I was experimenting with simple fluent APIs. One of the things I produced while doing so is a small library for building simple state engines which I call AbstractState. This library is available of GitHub under an Apache 2.0 licence. There are many cases where a full-blown workflow engine is impractical or undesirable but a simple state engine will nicely address the problem at hand. AbstractState addresses many of these cases by providing a simple mechanism to define and execute the permitted state transitions for a given type. The following example configures the permissible transitions for...
Index Part 0 – Introduction Part 1 – Persistence Part 2 - Domain Events A while back I watched Udi Dahan’s presentation on Making Roles Explicit and realised that it addressed a number of concerns with implementing and working with domain models that I didn’t even know I had. It’s rather awesome so I suggest you go watch it. I’ll wait. Based on these concepts Avernus seeks to provide: The infrastructure to support a role interface...
One of the rules in Microsoft’s FxCop static code analysis tool suggests that you should avoid empty interfaces. From MSDN: Interfaces define members that provide a behavior or usage contract. The functionality that is described by the interface can be adopted by any type, regardless of where the type appears in the inheritance hierarchy. A type implements an interface by providing implementations for the members of the interface. An empty interface does not define any members. Therefore, it does not define a contract that can be implemented. If your design includes empty interfaces...
Although no one seems to be able to come up with a name that makes everyone happy a .NET community exists and it produces some very nice tools. Properly utilised I believe these frameworks allow .NET developers the ability to write applications the equal of those on any other platform. Avernus is not an attempt to add another entry to this list. Rather it encapsulates one approach to using some of my preferred frameworks together. Most of the magic it provides is borrowed but I present this in the hope that someone will find my small additions helpful. (Does this...
I was asked recently if errors in an application should be handled in the business layer or in the UI. The answer to this is simple: Neither. Doing so is repetitive and unproductive. Error handling should be an automatic part of your infrastructure. It may seem that error handling is not something that can be performed automatically. But this is due to a broader definition of error than is applicable here. Conditions that are expected and probable during your applications execution are not errors, they’re use cases. If may be a user error that they have entered an invalid...