Perth Alt.Net - RavenDb

Last I did a "talk" on RavenDb at the Perth Alt.Net beers. I must say I was really stoked at the turn out. Lots of banter, comments, queries, theories and general discussion. I sincerely hope that everyone else enjoyed it as much as I did. I also felt that last night was moving closer to what I hope these events should be. These shouldn't be one-way dialogue. IMO the presenter is there to just start discussion and then it becomes a group affair, there should be lots of interjecting, lots of crowd participation. Last night there certainly was that and best of all it stay on track, we didn’t veer off into off-topic subjects (much) and I think the night was better for it.

I really do feel lucky to be in the company of some very smart people and i want to thank everyone for letting me bleat on and not give me too much grief for being woefully underprepared.

However I put it out there that the people who are comfortable enough to ask the hard questions (and there were a few), please take the reins, we want to hear from you! I’m a strong believe that you can learn as much about some from the questions they ask as the questions they answer and there were some gems last night.
Please contact Mike (@wolfbyte) or myself if you are thinking you may be interesting is starting a discussion, or even if you want to hear about stuff especially if it is edgy and possibly not suitable for the standard M$ .Net community of practice stream (Mitch wheat is the contact for that if you do have M$ specific stuff however). Any feedback is good. The hardest thing for organisers is trying to figure out what the crowd wants and as we nerds are not the most vocal people, making it even harder to run nerd events.

A further incentive is we now have sponsorship. If you get up and present you get swag, swag you want. I worked out since I have been back in Perth I have received several thousand bucks worth of cool stuff from presenting or attending various .Net events. It’s worthwhile getting involved!

Garry Stewart is up next time (in about 2 weeks) talking about light wieght IDEs, specifically VIm and letting go of our addiction that is Visual Studio.

One big note I also want to make. Take the talks for what they are. The whole under current of Alt.Net is "options". We need to be aware there are options. We are not saying you must throw away SQL and use RavenDB exclusively or Vi will replace Studio, we just want people to open their minds. If last nights talk got you thinking about how you could get you python web stck talking to cassandra, sweet, most of what we are talking about is concepts, if there is a tool involved, its just there because it facilitates a different way of thinking. Thats all.

See you next time :)

DDD eXchange 2010 - London

Un fortunately i dio not attend this event (which looked like an awesome event) however the Skills matter guys were good enough to post the videos of the event... sweeet!

DDD EXCHANGE 2010 - PODCASTS, SLIDES AND PICTURES

Thye have recorded all the DDD eXchange 2010 talks. The slides and podcasts can be viewed here:

• Keynote: DDD Emerging Themes of 2010 (Eric Evans)
• Architectural Innovation: CQRS (Udi Dahan)
• Architectural Innovation: Eventing, Event Sourcing (Greg Young)
• The 1st Parkbench Panel Discussion
  
• DDD Revelations and Misunderstanding: A Report from the Trenches (Ian Cooper)
• DDD, TDD, BDD (Gojko Adzic)
• Folding Together DDD & Agile (Eric Evans)
• The 2nd Parkbench Panel Discussion
  

You can also find some photos taken at the conference here.

Thanks SkillsMatter!

Test Fakes - Solving a Domain Entity Issue

Follow on from :Testing with Domain Driven Design

Background on the design in question

• We are using NHibernate for persistence on Oracle.
• We have service that accept command that are coarse grained and perform a clearly defined business function, they are not chatty services.
• We are using the notion of aggregate roots so all child objects are created and managed by the owning aggregate root. If you need to access the child it must be done via the AR
• The domain is relatively large and complex.

Background problem

We had issues where we were dealing with domain objects in test and getting problems with interrogating child collections. For example we sometimes need to be able to update a child of an aggregate root and we were using the id of the child (within our command object) to indicate which child to update. We are using a basic database identity field (oracle sequence) for setting the ids on all of our user defined entities.
Herein lies our problem;* In our test we create an aggregate root complete with child objects. We then want to test, for example, updating a child of the aggregate root via a DTO based command (i.e. using an id to define the child to update) and we run into issues when all of the child object have the same id of 0 as they are not persisted (it’s a unit test). Now this would never happen in real life. Why would you issue a command to update something that has not been persisted, how do you even know about that object?
The quick solution that I have seen used a lot is to set the ids of all of the domain objects prior to running the test. I don’t like this if you are doing this by exposing the ID setter on the domain object. This is opening up the API of our domain for testability and is potentially the start of a slippery slope in to a pit of hell. An easy way around this is to use fakes. These object are just child object of the domain objects in question that help expose stuff the domain shouldn’t; in this case the ID setter.
The other alternative is to set the id on creation of the fake so the setter of the id is not exposed. This can also work but it will mean your fake will always have an id set. For the situation I was in this was not suitable.

The end solution

All domain objects have a fake create for it. All of the fake implement an interface ISettableId. This interface is defined as below:

**CODE GOES HERE**

public interface ISettableId
{
    bool HasIdBeenSet();
    void SetId(TId id);
}

With an implementation example (its id type is and integer) :

public class FooFake : Foo, ISettableId
{
    public FooFake(string name, TypeRequiredForValidConstruction myDependecy)
    : base(name, myDependecy)
    {}
    public bool HasIdBeenSet()
    {
        return _id != 0;
    }
    public void SetId(int id)
    {
        _id = id;
    }
}

This mean we can now create fake objects and emulate persistence later by reflecting down the object graph and setting all of the ids. This is much faster than hitting the database and has proved to be a very valid exercise as we can now run tests again transient and persisted versions of the object graph without having a db connection.
One additional thing I should mention is that the creation of child object now must be exposed as a hook. For example when we create child objects I do not just new up to object and add it to a collection. I call a protected virtual method that creates the child object and then add that to the list. This allows my fake to override the return type that is added to the list so children can also be fakes. This has not increased the exposure of the domain but has now facilitate a hook to allow me to create fakes for my child collection.

Caveats:

Fakes should not include any logic. The fakes I am using only allow the setting of ids. The only logic they have is to check whether the id is set (this allows us to skip objects that have had their ids set when we walk the object graph and not go around in circles). The only other methods that are required is the overrides of the creation of child objects.
Other methods you may find in the fakes are builder methods. Instead of having big factories for creating test object you may choose to put the object creation closer to the owner by putting it in the fake class itself.

Summary

As I mentioned, we have a pretty large and complex domain we were running into issues where the difference between persisted and non persisted objects graphs was becoming problematic; using the fakes has allowed us to keep the domain clean and only as open as possible while allowing us to emulate persistence without the cost of hitting a database. Over all I’m pretty happy with the result.

*I’m sure there are other way to solve this higher level problem