Uniqueness in a DDD-CQRS-ES application

A while back I blogged that set based based concerns, i.e. duplicates, that when analyzed aren't really a problem. An example of this could a be a duplicate product in a catalogue. The worst that can happen is the user sees the item twice when browsing / searching. Everything still works - the customer can still purchase it, you can still ship it. It's low risk, low impact and life goes on.

There are situations though where global uniqueness is a real requirement, for example, choosing a username during a new user registration process. The problem here is that if a duplicate occurs you may have a security issue, or maybe neither user can log in. It depends on your application of course, but this may be considered high risk.

Read more...

Ensuring that Dispose() gets called on your IDisposable types

Here is a neat trick to make sure you IDisposable classes have their dispose method called. In the finalizer, call Debug.Fail and only include it in Debug builds:

public class DisposableClass : IDisposable
{
    public void Dispose()
    {
        //The usual cleanup
#if DEBUG
        GC.SuppressFinalize(this);
#endif
     }

#if DEBUG
        ~DisposableClass()
     {
        Debug.Fail(string.Format("Undisposed {0}", GetType().Name));
     }
#endif
}

This will give you an in-your-face dialog to let you know of your fail:

I can't claim that I came up with this, but I can't remember where I saw it either.

Read more...

Questions to ask whenever set based business concerns come up in a DDD-CQRS-ES based application

One of the biggest brain speed bumps for people who come from a centralized data-model first \ RDMBS world is the issue of duplicates. "What if we have duplicate names?" "What if we have duplicate accounts?" etc. This can be of special concern in distributed systems, where your aggregate roots may be created in different places.

Before I engage in any sort of implementation, I have several business questions that must be answered first:

Read more...