First look: Applying Domain-Driven Designs and Patterns

In an attempt to quench my thirst for all things C# and having already torn through the great .NET Framework Design Guidelines and less-great Effective C# I grabbed a copy of Applying Domain-Driven Design and Patterns (With Examples in C# and .NET) by Jimmy Nilsson.

The book is obviously based around domain models but also gives some coverage to test-driven development, NHibernate, design patterns, refactoring, code-smells etc.

This is only a first-look as I’m only up to page 130 of the 500+ the tome weighs in at but here are a few observations so far.

The Impedance Mismatch Between Domain Model and Relational Database

One annoyance with the book is that is identifies and discusses problems and then offers no discussion or ideas for a solution before moving onto another topic.

A good example is this section which touches on the mismatch between the primitive types of .NET and SQL without the consideration of how/where to check this, the fact that SQL types can be null with no regard to .NET 2’s INullable, bit flags or ‘magic values’.

How to Recognize If an Application Will Be Long Lasting

Another perfect example of the previous problem. The heading asks the question but the short anecdote about how a hacked together app became mission critical fails to answer it.

Use public fields

Jimmy proposes a number of techniques that fly in the face of .NET Framework Guidelines and other solid material. This is highlighted by the phrase;

As long as the fields are both readable and write-able and no interception is needed … public fields are at least as good as properties.

Perhaps Jimmy doesn’t know that converting a field to a property later will break binary compatibility with anything using your assembly.

Expose internals for testing

…expose sub-results so they are testable

flies in the face of hiding the implementation and Jimmy does at least refer to this balance but the whole idea of exposing unnecessary details for the sake of being able to test them gives me a shudder.

Throwing aside the whole question of whether you should write unit tests that test implementation rather than interface a better solution would be to add a

#if TESTING

block to classes that really need to expose their internals to your test tools and compile with that switch set in your testing environment.

Use static factory classes!

Jimmy extracts the factory methods into a new class and but then leaves them static. A static class throws away substitutability, extension and indeed everything that makes OO great for the sake of being able to access it like a global variable.

Expose IList as read-only

On page 102 Jimmy refactors a “public IList Children” field firstly making it a read-only property and then creates a AddChild method which is fine but then how will he stop people modifying his IList? With ArrayList.ReadOnly(children) of course bemoaning how clients still see .Add etc.

Hello Jimmy, let me introduce you to IEnumerable.

Use reflection to set internal properties from Factory & Repository!

Jimmy describes how some properties should be read-only but then the Factory and Repository need to set the values. He proposes reflection.

Maybe Jimmy missed the memento pattern and dislikes the internal keyword.

Coding standards

All the code samples use _ for internal members — something that Microsoft guidelines and their FxCop tools are keen to stamp out. Besides being ugly it also reeks of the obsolete Hungarian naming prefixes.

Storybook format

The whole book is written in “I still remember”, “I worked on an application”, “After that, I tried Domain Models”… It makes for slow reading at times.

Well that about wraps it up so far.

[)amien

8 responses to First look: Applying Domain-Driven Designs and Patterns

  1. Avatar for

    Information is only used to show your comment. See my Privacy Policy.

  2. Avatar for Ha Vo

    DDD technique is what I’ve been using to develop enterprise application for the last few years. I’d never thought it’d be called Domain-Drive Designs and be a hit on the internet. Now I just need some good sample codes on how to sort custom object collection…and I mean really really fast (no Reflection please).

  3. Avatar for Colin Jack
    Colin Jack

    Nope, mind you it might just be the two of us :)

    To some extent the book works especially early on. In fact even in chapters 6/7 its covering the issues I want to know about but I’m always left thinking “Yeah but what about..", “Nooooo, don’t stop there…", “Hold on, how does that solve the problem”, “Well he might mean this, or does he mean this” or whatever.

    That’d be fine if I was reading a theoretical text but not with this book as it really doesn’t cover much theory. In fact I almost think I’d have enjoyed this book more if I wasn’t using it whilst trying to work in a domain driven manner, because I probably wouldn’t have noticed that it didn’t have the details that I’m interested in.

    I guess I might stop reading it and will come back to it in 6 months once i’ve been doing more DDD/database development and have read the book by Eric Evans.

    Actually Dave Hayden makes a good point:

    That being said, I think the market is ripe for a person(s) to author a book that expands upon Jimmy’s ideas. A book that implements and discusses the following design techniques mentioned above into an actual executable application using open source tools like NHibernate, Spring.NET, NMock, NUnit, etc., would be the icing on the cake and a sure winner.

  4. Avatar for Damien Guard

    That’s a relief — from the number of positive reviews and comments I was beginning to think that it was just me…

  5. Avatar for Colin Jack
    Colin Jack

    Very interesting and its good to hear someone else is having trouble with the book! :)

    I agree with most of what you said but I’ve also found that the later sections have their own troubles.

    I read through the first 100 pages quite quickly, I’ve read about TDD/refactoring before so wasn’t that interested in this part (Robert C. Martins book has great coverage of the TDD cycle).

    I then got into chapter 4 which was good, chapter 5 was also quite interesting so I was beginning to enjoy it.

    However I think things took a big down turn in chapters 6/7, and I think its because the style changes as there are less code examples and things are covered at a higher level. Instead of discussing the process we end up going directly to the solution (Jimmy indicates this is what he wanted to do). However this, and the writing style, causes me problems for a few reasons:

    1. In many cases I don’t understand what Jimmy is saying, I’m almost embarassed to admit it but its true :)
      2) Even if I think I understand the text is vague enough that I’m not 100% sure that I’m correct, especially given that the wording/English used can sometimes lead to misunderstandings.
      3) The devil is in the detail and the most interesting sections lack detail. I’d far prefer if the first 100 pages were cut and chapters 6/7 were really fleshed out.

    I agree with you completely that lots of questions are asked without the answers being provided, or the answers are given at such a high level that its difficult to work out how you’d apply them. I know the author is an expert so I’m finding it quite frustrating.

    I also agree that the overly personal style begins to grind after a while, atleast for me. I think part of the problem is that before starting this I read Robert C. Martins excellent Agile Principles book and the styles of the two authors couldn’t be more different so I went from reading one book that I really enjoyed (partly due to the excellent examples of everything that is discussed) to another that I’m finding to be a real struggle.

    Oh and I agree about “.NET Framework Design Guidelines” being superb.

  6. Avatar for Gabriel Lozano-Morán

    4 remarks:

    1.
    Factory classes imho should be static because I don’t want to create a new instantion of the factory classes each time i need to call the Create method. If you need extensibility you could apply the Provider design pattern by adding the provider to load in the config file and then in the type initializer of the factory class load that provider and each time you call the Create method you delegate the Create to the loaded provider.

    2.
    What Jimmy meant by making the IList read-only was to make sure that the IList does not get replaced by another IList but instead IList manipulation is controlled through seperate methods

    1. Expose internals for testing!
      This is called “Friend Assemblies” assembly:InternalsVisibleTo("") a commonly used technique for unit testing.
    2. Coding standards
      The coding standards are guidelines whether you follow them or not is merely a matter of taste. There are a lot of examples in the MSDN Library where the coding standards are not respected either. Furthermore in a lot of companies they use their own coding standards so I can imagine that people use different coding standards.

    I agree that that some of the points Jimmy makes in his book might seem awkward I do still appreciate that he wrote the book.

  7. Avatar for Damien Guard

    The _ is a minor issue.

    Let me know how you get on with the book — I’d be interested to know if I missed/didn’t get some of the good content out of it.

  8. Avatar for Dennis van der Stelt

    Your comments are mostly on technical side of things. I haven’t read the book but I hope there’s more to be told about DDD then technical details! :)

    Two observations from my side though:

    The public fields; Jimmy says they’re fine if the implementation will never change, according to your comment. So you’ll never break binary compatibility! :) But still, I’d prefer properties over fields. And in VS2005 the “prop” smarttag rules :)

    And about the coding standards; I still use _ for internal members, because it’s more clear what you’re using, class or method variables.

    Oh, gotta go :)