Tuesday, 23 September 2014

DDD Validation

Validation within an application (specifically in terms of Domain Driven Design - DDD) can be solved in a variety of ways.

  • A validate method on the entity/value type in question
  • An IsValid property/accessor on the entity/value type in question
  • A separate service could be used

Validate Method

Adding a validate method would work, but the flaw with this approach is that you lack any context of what is happening to the object in question.

Validate Flag

Some sort of flag on the object that denotes whether or not the object is in a valid state is undesirable. Firstly it forces the developer to ensure they check this at the correct time. If the object is invalid, exactly what do you do at this point? This approach is often used with a combination of a validate method that returns the exact error messages.

Validator Services

A separate service seems less than ideal at first when you consider developing a richer domain model, but this solution has numerous benefits. Firstly unlike the two solutions above you always have the context in which validation is being performed. For example, if you are saving a customer you will most likely want to perform different validation to what you would perform when loading up an aggregate.

An additional point to consider is that most validation is not business logic. In other words, checking for null references is not a business concern. Therefore separating this from your domain objects makes a lot of sense. The only logic the domain objects should contain is business logic.

As each service is a separate object, you gain the benefits of the single responsibility principle (SRP). Meaning testing, development and future changes are easier.

Example

The beauty here is that each validator (a simple function in this case) can be used in the correct context. E.g. when the PersonController POST handler is invoked, we use the person saving validator.

Tuesday, 16 September 2014

Developer Diaries

A few weeks back I stumbled across a tweet which I unfortunately cannot find to give credit to. It talked about the benefit of keeping a developer diary.

At the same time I was reading Getting Things Done (GTD). I felt inspired to take note of everything related to development that I do during my day to day time. This would satisfy the criteria I had for my GTD system, along with trying to emulate the success the original tweet was referring to.

I don't have a fancy system. Rather I have a text file that is distributed between the numerous desktops and laptops I have access to. Here the file is synced, so I should always be up to date. Dropbox handles this for me.

Each day I simply make a note of anything I think "I must remember that" or anything that happens to be useful, interesting or new. There is no complex system to this in order to keep in aligned with GTD, new points are simply appended at the bottom of the file. At the end of each week I simply group up related notes. For example, if I've got a few bullet points about databases, I move these to fit under a "Database" heading. This system works for now, though I might have to re-asses this in the future. An example of the file is below.

Example

The most surprising thing about this, is that even on a dull day I absorb a lot of "stuff" related to development. Equally surprising is how awful my memory is regarding it. If I skim across the document now, I'm alarmed at the stuff that I would have forgotten had I not taken a note. It's quite possible that I would remember some of this information in the long term, but regular skim readings of the diary is proving very helpful.