Tag Archives: ddd

My Clojure Journey: Simple Expressive Tests

Posted on by
Reply

One thing my team has struggled with in enterprise C# development is the complexity of unit test setup. This is complicated by Domain Driven Design, which encourages the use of concrete classes for entities and values. Test setup often becomes nontrivial as you are often required to set up considerably more of the object graph than what’s really necessary for the test at hand, simply because of the constructor signature on, say, a value object that you want to test.

This is much less of a problem in a dynamic language like Clojure, where there are no hard and fast rules about constructing objects – you can just create a map with only the properties you need for the test. For example, here’s a test in my Hearts project that invokes a function named next-player-pos and passes it a game of Hearts, which here is simply represented as an empty map {}:

(deftest next-player-at-start-is-first-player
  (with-redefs [first-player (constantly {:pos 2})]
    (is (= 2 (next-player-pos {})))))

Continue reading →

Branching by Abstraction

Posted on by
1

Last month we shipped an update to our website that didn’t add any features, but was a major refactoring for us. We moved the thousands upon thousands of user accounts in our system out of our old file “database” if you will, into a document database called RavenDB. But more importantly, we also completely redesigned the class representing the user account itself from the ground up using Domain Driven Design (DDD) techniques: entities, immutable values, repositories, etc.

The update was scripted and went off very smoothly (we were only down for about 20 minutes during the conversion, which also included an upgrade of the Raven database itself). But what’s more interesting to me is the approach we took in getting there. Instead of having a team go dark on a branch, do the redesign all at once, then do a massive merge and ship, we took an incremental approach, what Paul Hammant coined, Branch by Abstraction. Many shops do this without knowing about Paul’s article, which I found when we were in the middle of the process. Paul’s words helped give me courage that our approach was sound, and I wanted to share our success with our readers.

Continue reading →

What’s the Single Responsibility of an Entity in Domain Driven Design?

Posted on by
2

When I was first getting my head around Domain Driven Design (DDD), I had a hard time reconciling Entities with the Single Responsibility Principle. By their very nature, some entities can have an awful lot of state hanging off them.

Take for example our UserAccount entity at Pluralsight. There’s a lot of stuff associated with a user account:

  • The Id for the account, making it unique
  • Profile information that allows the user to customize her experience (name, email, etc.)
  • A password verifier that allows us to authenticate the user
  • Statistics about the account – when was it created? When was the last time the user logged in?
  • Preferences for the user – does she prefer our Silverlight or our WM player?
  • Subscription for the user – does she have a Plus subscription? A trial? etc.
  • and the list goes on…

Looking at all of this, it sure makes it hard to see what the single responsibility of the UserAccount should be.

I remember struggling with this and going back to the Evans book for guidance. Fortunately he didn’t let me down – it’s all in there as clear as day. It just takes a knucklehead like me a couple of reads to really get it:

When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model. Keep the class definition simple and focused on life cycle continuity and identity.

There’s more to it than this, and I encourage you to study part 2 of the DDD book to derive your own opinion, but one thing has been crystallizing for me:

The single responsibility of an Entity is to identify itself uniquely in a sea of other Entities.

In other words, I should be able to find the Entity by its ID, or possibly by other searchable attributes. Each UserAccount entity has a unique Id, and I can use the corresponding repository to find a particular UserAccount from among the thousands of accounts at Pluralsight by simply supplying an Id. But I can also supply an Email address and find the account that way. I can search for all UserAccount objects that have a last name of “Simpson”, etc.

What’s UserAccount’s single responsibility? Being findable.

So what about all of that other state that’s hanging off of the UserAccount? What about the Preferences? The Subscription? There’s a lot there that has nothing at all to do with the lifecycle or “findability” of the UserAccount. Doesn’t that violate SRP?

Nope!

It turns out that if you adhere to the guidelines of DDD, you’ll end up packaging all of that other state into separate classes (Value Objects) that break it down into smaller, more manageable chunks. The Entity then delegates responsibility to these classes, keeping the Entity class itself simple and focused on findability.

For example, when you look at our UserAccount class, you’ll see a property of type UserPreferences hanging off of it. UserPreferences is a class representing a Value Object that tells us which player the user prefers, whether she likes to see the course catalog expanded or collapsed, and so on. By the simple act of pushing that responsibility down into the UserPreferences class, the UserAccount class no longer has responsibility for worrying about that stuff. The UserAccount simply needs a getter and a setter so the UserPreferences can be updated, but it doesn’t need to care about the business rules of getting and setting individual preferences. That’s the responsibility of the UserPreferences class.

Following this guidance, our UserAccount object has become surprisingly simple.

What’s your experience with Entities been like? Comment on this post to share your challenges!

Domain Driven Design in C# – implementing immutable value objects

Posted on by
3

In his book, Domain Driven Design (DDD), Eric Evans encourages the use of Value Objects in domain models. Here at Pluralsight we are using the DDD approach to modeling, and we are taking his advice and using immutable objects to implement all of our Value Objects in our domain layer. What we’re finding is that we are programming in C# but our code is becoming more and more functional in nature, which has lots of benefits. Less mutable state tends to make things easier to test, and tends to reduce bugs.

Sure you can hide an object’s state behind public methods and property getters, but if you really want to implement immutable objects, you should consider surfacing the class’s internal state via readonly fields. Indeed it becomes as simple as this:

public class Cooldown {
  public readonly string Ability;
  public readonly DateTime ExpiresOn;
  // ... several more fields

  public Cooldown(string ability, DateTime expiresOn, ...)
  {
    Ability = ability;
    ExpiresOn = expiresOn;
    // etc.
  }
}

Prior to .NET 4.0 this wasn’t very easy to do. And that’s because objects in C# with readonly fields require that those fields be initialized by a constructor. Imagine a call to a constructor for an object with several arguments – this can get unreadable very quickly. What does “Foo” correspond to? “Bar”? Ugh.

new Cooldown(
    "Invisibility",
    DateTime.UtcNow.AddSeconds(30),
    "Foo",
    42,
    "Bar",
    ...);

But this awkwardness goes away with .NET 4.0. Now I can construct a readonly object and not lose any clarity around what each argument means, because I can call the constructor using named arguments.

new Cooldown(
  ability: "Invisibility",
  expiresOn: DateTime.UtcNow.AddSeconds(30),
  ...);

This looks remarkably similar to object initialization syntax, which uses property setters. It’s certainly no harder to type, and it’s just as easy to read.

One gotcha to this approach is that many data binding frameworks will only bind to property getters, ignoring public fields. This isn’t a problem for us here at Pluralsight, because our domain model is isolated from tech like this. Data binding frameworks don’t come into play until you’re up in our application layer, and in that layer we use separate view model classes that do have property getters and setters to play nice with ASP.NET MVC, the Razor view engine, etc.

A second gotcha is that there aren’t any mainstream serializers or O/R mappers that I know of that know how to rehydrate an immutable object via its constructor. Even AutoMapper can’t handle this today. Most of this tech relies on calling a default constructor to get an instance of an object, then calling property setters (or setting the values of fields) to rehydrate its state. But once again, this is not a problem at all here at Pluralsight, because our domain objects aren’t directly serialized – our persistence layer has a set of data transfer objects that are designed to be serializer friendly. And we explicitly avoid AutoMapper in favor of code gen’d mappers which are friendlier to refactoring tools like ReSharper.

The beauty of all of this isolation is that we are establishing a pristine domain layer devoid of tech, leaving only concise business logic. We’ve even managed to eliminate the need for GetHashCode until it’s absolutely needed!

How to reduce ambiguity in C# method calls using named arguments

Posted on by
2

As of .NET version 4.0, C# supports named and optional arguments. This comes in really handy for distinguishing method parameters that have the same type. For example:

public interface IGenerator<T>
{
    T Generate(T min, T max);
}

It would be really easy to accidentally pass arguments to Generate in the wrong order, since they have the same type. But using named arguments, you can make your code very clear:

var n = generator.Generate(min: 0, max: 42);

I try to follow the rule that no method should take more than two arguments, so I end up using this technique most often with constructors, which often need to take a lot of parameters. But more on that in another post!

Domain Driven Design in C#: Equals and GetHashCode – part 5

Posted on by
8

This series of posts starts here, covering some discoveries I’ve made about implementing equality semantics in DDD, test coverage of equality, etc. I last left off by concluding that I didn’t want to implement Equals or GetHashCode until I had a good reason to need either of them. But seeing as they surface by default via System.Object, I was in a bit of a quandary, because the default implementation is wrong for both entities and value objects in DDD.

To wrap up this journey, let me post some conclusions at which I’ve arrived. As with any conclusions I make, I’ll have to look back in a year to see if I still agree with them, and I’d love to hear what you think, so please drop a comment here!

1. I really wish System.Object didn’t surface equality. The default implementation is almost always wrong, and it’s easy to screw up and difficult to maintain when you provide a custom implementation. It’d be nice if we could simply add these semantics incrementally by implementing IEquatable<T> (we’d also need a corresponding IHashable) but we’re stuck with the legacy of the CLR and its roots in Java. Sigh.

2. Given that System.Object *does* surface these methods, our team has developed a little shim class designed to sit right under System.Object. We call it PsObject. We’re using this as the root of our class hierarchy instead of System.Object. PsObject does three things that have significantly simplified the classes in our domain:

  • PsObject overrides Equals and throws NotImplementedException. YAGNI, baby! If we find a need to use Equals on an entity or value object, we’ll take the time to implement it with TDD and get 100% test coverage.
  • PsObject overrides GetHashCode and throws NotImplementedException. This way we don’t feel compelled to implement GetHashCode just because we implemented Equals – gasp! If we ever decide to use one of our classes as a key in a dictionary, we’ll pause and TDD GetHashCode to make that possible.
  • PsObject overrides ToString and uses reflection to emulate the code that ReSharper would normally generate via “Formatting Members”. We no longer need to add (and maintain!) custom ToString implementations to every class just to make them look nice in the debugger. If we ever need something more meaningful than this default diagnostic implementation, we’ll TDD a custom ToString implementation.

3. We’re switching to use reference comparisons in unit tests where appropriate to avoid testing too much or thinking that we need custom Equals implementations everywhere just for unit testing. Thanks Shawn!

One final conclusion. Who knew that Satan worked at JetBrains? Don’t get me wrong, I love ReSharper and wouldn’t want to live without it. But its “Generate Equality Members” feature is evil. Our team has agreed not to use this feature unless we’re writing throwaway code. We’ve agreed to always use TDD to develop Equals and GetHashCode from now on.

 

Domain Driven Design in C#: Equals and GetHashCode – part 4

Posted on by
Reply

In my last three posts, I gave some background about how we’re using DDD and TDD and how we’ve been overriding Equals and GetHashCode to provide semantically correct equality for our domain objects. It’s felt convenient because unit tests could make use of Assert.AreEqual to compare value objects and entities, and our slide into the abyss was generously lubricated by ReSharper‘s code generation feature for Equals and GetHashCode.

So I went home that night and took a step back. I started searching to see how others were dealing with object equality in unit tests, and I came across a great post by Shawn Finglas, over at CodeWeavers. After reading the first couple of paragraphs, I realized that a lot of our tests were testing too much by using AreEqual assertions. We really should have engineered the tests so they could simply test the output using reference equality semantics (AreSame). My unit tests were turning into mini integration tests. What’s funny is that I knew this on some level – those smells again, but until I read Shawn’s post, it didn’t really click for me.

So I thought about a world where I didn’t rely on Equals in my unit tests. Suddenly it became clear to me – I didn’t need Equals at all. I’d been violating YAGNI. I hadn’t yet discovered a real need for custom equality semantics on my domain objects, and yet I was aggressively implementing it in my fervor to adopt DDD.

But what would be the effect of removing my custom implementations? Because all objects inherit a default reference equality implementation from System.Object, as soon as someone *found* the need to use Equals on one of my domain objects, they’d get the wrong implementation! Reference equality is wrong for both entities and value objects.

Tensions, tensions, tensions.

Continue to the next post in this series.

Domain Driven Design in C#: Equals and GetHashCode – part 3

Posted on by
Reply

In my last posts, I talked about how we’re using DDD to approach design, and TDD in our implementation, and how we found ourselves taking shortcuts by implementing equality using ReSharper‘s code gen feature.

One practical offshoot of implementing equality semantics on an object is that you can use Assert.AreEqual() in tests and it’ll be meaningful. Besides the pressure wanting to do DDD “correctly”, this also added pressure to implement equality – it sure seemed to make the tests more natural when comparing value objects. Recently a team member pointed out that the only place our custom equality implementation was being used was in unit tests. We weren’t using it at run time at all. The smell coming from our domain just got worse.

A couple of days ago, another member of the team pointed out that the test coverage of our custom equality implementations was really low. That seemed strange because we were using those methods in our unit tests. Of course we weren’t directly testing those methods for correctness, we were just using them in assertions for operations that returned those value objects. We knew that we weren’t doing TDD for those methods, and we felt like that was wrong, but since they were only being used in tests, and testing equality can be incredibly tedious, we felt like maybe it was okay to be lazy.

At this point the smell was so overwhelming that we had to stop what we were doing. The first step in solving a problem is admitting that you have one. Sometimes that’s the hardest part, isn’t it?

At first our discussion centered on how to get test coverage around equality. Should we go back and retrofit tests around all of our Equals implementations? And GetHashCode? For a value object class with a number of fields this can be really, really tedious. How could we justify taking the time to do that when we weren’t really relying on equality anywhere except in our test code? The obvious answer to this was, “you want your tests to be correct, don’t you?” So our discussion turned to tooling like Pex from MS Research. Maybe we should research a tool like that, which automatically generates tests with different permutations of input.

I told the team that since I’d gotten us into this mess, I’d go home and do some research to come up with some options on how to proceed. And what I discovered was pretty cool.

Continue to the next post in this series.

Domain Driven Design in C#: Equals and GetHashCode – part 2

Posted on by
Reply

In my last post, I talked about the difference between entities and value objects in terms of how you’d overload Equals and GetHashCode. One thing is clear: the default implementation of equality and hashing supplied by Object in C# (and object in Java) are incorrect for both entities and values.

As we’ve been implementing entities and value objects in our domain, we’ve consciously been adding proper implementations of Equals and GetHashCode based on whether the class represents an entity or a value.

Now I must diverge for just a moment to weave in another thread: Test Driven Development (TDD). Every day, in every way, we’re getting better and better at doing TDD. It’s a journey, as anyone who has done TDD knows. But I must admit, we succumbed to the siren song of tooling on our Equals and GetHashCode implementations. ReSharper has a very tempting feature that will generate code for these methods automatically based on shallow equality semantics. You just select the fields on which you want to base your implementation, and ReSharper works its magic, generating some very clean code for Equals and GetHashCode. It’ll also override ==, !=, implement IEquatable<T>, and wash your dishes for you. We took this shortcut because we believed we needed to implement proper equality semantics on our entities and value objects. We’re doing DDD after all, and this seemed to make it easier.

Of course, wherever we had hierarchies of value objects, shallow equality wasn’t good enough – we’d need to hand-tweak ReSharper’s generated equality code to perform deep comparisons. For example, if a value object class holds a collection, ReSharper would simply perform a reference comparison on the collection itself, which is not at all useful. We’d turn that into a call to Linq’s SequenceEqual to force a deep comparison. When we started having to do this, a smell started wafting up from our code.

Implementing Equals properly can be hard. It’s one of those methods that’s easy to screw up, especially as a class changes over time. When you add a new field to a value object, are you going to remember to update your Equals override? What about your hash code? We were using a code generation trick to generate some of the most complicated methods in our value objects. And it felt like magic, for a while.

Continue to the next post in this series.

Domain Driven Design in C#: Equals and GetHashCode – part 1

Posted on by
Reply

As our dev team here at Pluralsight continues its journey into Domain Driven Design, we’re constantly learning how to do it better.

One of the most important differences between an entity and a value object is equality semantics. In DDD, entities typically have a unique symbol associated with them, say a property called “Id”, that you’d use for comparing one with another. If you were to override Equals and GetHashCode, you’d only compare the Id and ignore any other attributes on the entity.

Value objects on the other hand don’t need an Id – they are simply defined by their attributes (Evans likens them to crayons – you don’t really care which one you’re using, only that it’s the right color – it has the attributes you need). When you override Equals and GetHashCode on a value object, you include all of the attributes of the object in the comparison. If any of them differ, the value objects are different.

This has some interesting consequences when implementing DDD in C# (and Java), where equality and hash codes support are supplied by the mother of all base classes, Object.

Continue to the next post in this series.