One of the applications I work on is a planning system, used for managing the operations of the business over the next week, month and financial year.

Almost every entity in this application has a fixed ‘applicable period’ — a lifetime that begins and ends at certain dates. For example:

• An employee’s applicable period lasts as long as they are employed
• A business unit’s lifetime lasts from the day it’s formed, to the day it disbands
• A policy lasts from the day it comes into effect to the day it ends
• A shift starts at 8am and finishes at 6pm

Previous incarnations of the application simply added StartDate and EndDate properties to every object, and evaluated them ad-hoc as required. This resulted in a lot of code duplication — date and time logic around overlaps, contiguous blocks etc were repeated all over the place.

As we’ve been carving off bounded contexts and reimplementing them using DDD, I’m proud to say this concept has been identified and separated out into an explicit value type with encapsulated behaviour. We call it a Time Period:

It’s sort of like a .NET TimeSpan but represents a specific period of time, e.g. seven days starting from yesterday morning — not seven days in general.

Here’s the behaviour we’ve implemented so far, taking care of things like comparisons and overlapping periods:

/// <summary>/// A value type to represent a period of time with known end points (as/// opposed to just a period like a timespan that could happen anytime)./// The end point of a TimeRange can be infinity. /// </summary>public class TimePeriod : IEquatable<TimePeriod>{    public DateTime Start { get; }    public DateTime? End { get; }    public bool IsInfinite { get; }    public TimeSpan Duration { get; }    public bool Includes(DateTime date);    public bool StartsBefore(TimePeriod other);    public bool StartsAfter(TimePeriod other);    public bool EndsBefore(TimePeriod other);    public bool EndsAfter(TimePeriod other);    public bool ImmediatelyPrecedes(TimePeriod other);    public bool ImmediatelyFollows(TimePeriod other);    public bool Overlaps(TimePeriod other);    public TimePeriod GetRemainingSlice();    public TimePeriod GetRemainingSliceAsAt(DateTime when);    public bool HasPassed();    public bool HasPassedAsAt(DateTime when);    public float GetPercentageElapsed();    public float GetPercentageElapsedAsAt(DateTime when);}

Encapsulating logic all in one place means we can get rid of all that ugly duplication (DRY), and it still maps cleanly to StartDate/EndDate columns in the database as an NHibernate component or IValueType.

You can grab our initial implementation here:

• TimePeriod.cs
• TimePeriodTests.cs

Working on a legacy application that uses over 2,200 stored procedures, it can be hard to keep track of which ones are still active and which can be deleted.

Here’s a quick PowerShell script I wrote that locates stored procedures in a database that aren’t referenced by code or other database objects (assuming you have them scripted in source control).

# find un-used stored procedures# ---------------------------------------------------------# C# files$src = "C:yourprojectsrc"# db objects (e.g. DDL for views, sprocs, triggers, functions)$sqlsrc = "C:yourprojectsqlscripts"# connection string$db = "Data Source=localhost;Initial Cataog..."# ---------------------------------------------------------echo "Looking for stored procedures..."$cn = new-object system.data.SqlClient.SqlConnection($db)$q = "SELECT        nameFROM        sys.objectsWHERE        type in ('P', 'PC')        AND is_ms_shipped = 0        AND name NOT IN        (                'sp_alterdiagram', -- sql server stuff                'sp_creatediagram',                'sp_dropdiagram',                'sp_helpdiagramdefinition',                'sp_helpdiagrams',                'sp_renamediagram',                'sp_upgraddiagrams'        )ORDER BY        name ASC"$da = new-object "System.Data.SqlClient.SqlDataAdapter" ($q, $cn)$ds = new-object "System.Data.DataSet" "dsStoredProcs"$da.Fill($ds) | out-null# chuck stored procs name in an array$sprocs = New-Object System.Collections.Specialized.StringCollection$ds.Tables[0] | FOREACH-OBJECT {        $sprocs.Add($_.name) | out-null}$count = $sprocs.Countecho "  found $count stored procedures"# search in C# filesecho "Searching source code..."dir -recurse -filter *.cs $src | foreach ($_) {        $file = $_.fullname        echo "searching $file"        for ($i = 0; $i -lt $sprocs.Count; $i++) {        $sproc = $sprocs[$i];                if (select-string -path $file -pattern $sproc) {                        $sprocs.Remove($sproc)                        echo "  found $sproc"                }        }}# search in NHibernate *.hbm.xml mapping filesecho "Searching hibernate mappings..."dir -recurse -filter *hbm.xml $src | foreach ($_) {        $file = $_.fullname        echo "searching $file"        for ($i = 0; $i -lt $sprocs.Count; $i++) {        $sproc = $sprocs[$i];                if (select-string -path $file -pattern $sproc) {                        $sprocs.Remove($sproc)                        echo "  found $sproc"                }        }}# search through other database objectsdir -recurse -filter *.sql $sqlsrc | foreach ($_) {        $file = $_.fullname        echo "searching $file"        for ($i = 0; $i -lt $sprocs.Count; $i++) {                $sproc = $sprocs[$i];                if ($file -notmatch $sproc) {                        if (select-string -path $file -pattern $sproc) {                                $sprocs.Remove($sproc)                                echo "  found $sproc"                        }                }        }}# list any that are still here (i.e. weren't found)$count = $sprocs.Countecho "Found $count un-used stored procedures."for ($i=0; $i -lt $count; $i++) {        $x = $sprocs[$i]        echo "  $i. $x"}

It ain’t too pretty, but it does the job.

Unit tests for private methods are a code smell

This week I attended a talk where some people were discussing techniques for unit testing private methods — they were going on about problems they had getting something called Private Accessors to work with ReSharper.

The tools they mentioned were completely foreign to me, and I wondered why I’d never heard of them. I think the reason is because I never bothered trying to test a private method before.

I take the approach that, if you have a private method worthy of having its own tests, then it is worthy of being extracted to a public method on a new class. Tests for private methods are a big smell you have an SRP violation somewhere. And they will be brittle anyway so just don’t do it!

Domain model refactoring: replace query with composition

Here’s a snippet of ubiquitous language (altered slightly to protect the innocent) from a system I’ve been working on over the past few months:

An Officer is a role played by certain Employees. Each Officer is required to be proficient in a number of Competencies, according to [among other things] what District they’re stationed in.

We originally implement the Officer-District association as a query because it comes from a different bounded context (Rostering) and changes frequently as Employees move around.

When creating an Officer role for an Employee, we simply queried to find out what District they were working in and what Competencies are required to be practiced there. It looked something like this:

public class OfficerRoleFactory : IRoleFactory<Officer>{    ...        public Officer CreateRoleFor(Employee employee)    {        District district = districtResolver.GetCurrentLocationOf(employee);        var requiredCompetencies = competencyRepository            .GetCompetenciesRequiredToBePracticedIn(district);                return new Officer(employee, requiredCompetencies);    }}

That was great for when someone first became an Officer, but presented a big problem when they want to move to a different District. To update their required Competencies we have to:

1. Find what Competencies were required because of their old District
2. Find what Competencies are required in their new District
3. Add new required Competencies to the Officer and remove any that no longer apply

Our model did not easily permit this because it failed to encapsulate what District an Officer was working in when their required Competencies were assigned (we simply queried for their current location whenever it was needed). Our code got stuck:

public class Officer : IRole{    ...    /// <summary>    /// Change the District the Officer is working in. Removes any    /// Competencies no longer required to be practiced and adds    /// new ones.    /// </summary>    public void ChangeDistrict(District newDistrict)    {        var oldCompetencies = competencyRepository            .GetCompetenciesRequiredToBePracticedIn(/* what goes here? */);        var newCompetencies = competencyRepository            .GetCompetenciesRequiredToBePracticedIn(newDistrict);       this.requiredCompetencies.Remove(oldCompetencies);       this.requiredCompetencies.Add(newCompetencies);    }}

An Officer’s old District simply wasn’t defined anywhere.

Make everything explicit

Even without updating Competencies to reflect staff movements, we foresaw a lot of confusion for users between where Training thinks you are and where the Rostering says you actually are.

We decided the best way to resolve these issues was to make the Officer-District association a direct property of the Officer that gets persisted within the Training BC:

It seems like a really simple conclusion now, but took us a while to arrive at because our heads were stuck in the rest of the system where pretty much everything (legacy dataset-driven code) queries back to the live Roster tables. Instead we should have been focusing on domain driven design’s goal of eliminating confusion like this by making implicit concepts explicit:

public class Officer : IRole{    /// <summary>    /// The District the Officer is currently stationed in. He/she must    /// be proficient in Competencies required there.    /// </summary>    public District District { get; set; }        ...    /// <summary>    /// Change the District the Officer is working in. Removes any    /// Competencies no longer required to be practiced and adds    /// new ones.    /// </summary>    public void ChangeDistrict(District newDistrict)    {        var oldCompetencies = competencyRepository            .GetCompetenciesRequiredToBePracticedIn(this.District);        var newCompetencies = competencyRepository            .GetCompetenciesRequiredToBePracticedIn(newDistrict);       this.requiredCompetencies.Remove(oldCompetencies);       this.requiredCompetencies.Add(newCompetencies);              this.District = newDistrict;    }}

Benefits

Refactoring away from the query to simple object composition makes our domain model a lot easier to understand and also improved some SOA concerns and separation between BCs:

• ‘Where the Training BC thinks you are’ is now an explicit and observable concept. This clears up a lot of confusion both for users wondering why certain Competencies are assigned to them, and developers trying to debug it.
• It breaks an ugly runtime dependency between the Training and Rostering BCs. Previously, if the DistrictResolver failed for some reason, it would block the Training BC from succeeding because it was called in-line. Now we can take that whole Rostering BC offline and Training won’t notice because it knows for itself where each Officer is stationed.
• It allows us to deal with staff movements in a much more event-driven manner. Instead of the DistrictResolver returning up-to-the-second results each time, the District is now an explicit property of the Officer aggregate root that only changes when we want it to — e.g. in response to a StaffChangedDistrict domain event. We can now queue these events and achieve better performance via eventual-consistency.

Overall I am very happy with this.

Assuming the following tables:

CREATE TABLE Shopping.Product (CategoryID INT NOT NULL)CREATE TABLE Shopping.Category (CategoryID INT PRIMARY KEY)ALTER TABLE Shopping.Product    ADD CONSTRAINT FK_Product_Caetgory FOREIGN KEY(CategoryID)    REFERENCES Shopping.Category

There is a typo in the foreign key name. How would you fix this using sp_rename? Is it…

-- 1. Just the object name as seen in sys.objects:sp_rename 'FK_Product_Caetgory', 'FK_Product_Category', 'OBJECT'-- 2. Qualified with  the schema:sp_rename 'Shopping.FK_Product_Caetgory', 'FK_Product_Category', 'OBJECT'-- 3. Qualified with the schema and table:sp_rename 'Shopping.Product.FK_Product_Caetgory', 'FK_Product_Category', 'OBJECT'

If you picked #2, you are correct. This took me 10 mins to figure out.

A few days ago I read a really great post by Seth Godwin about Traction and Friction. He’s not a programmer (as far as I know), but writes a lot of insightful articles about strategy and value that can be applied to everyday subjects.

This particular article struck a chord in me as a good metaphor for the benefits domain-driven design brings to object-oriented code. Here’s a snippet:

A big car on a wet frozen lake goes nowhere. No traction, no motion.

A small bug working its way across a gravel driveway takes forever. Too much friction, too little motion.

If you’re stuck, it’s probably because one of these two challenges.

…

The power of online platforms is that they create traction. No, you can’t write more than 140 characters, no you can’t design any layout you want, no you can’t spam everyone with your inane sales pitch. You have something to leverage against, but it’s that thing, the friction, that makes it work.

Object-oriented languages like C# or Java are very powerful things. They provide an infinite canvas on which you can create just about anything, including a huge mess — like the car on the frozen lake — if you start coding without any rules to guide you.

DDD on the other hand provides principles and patterns you can leverage and push off with, like the side of a swimming pool. No you can’t put UI logic in the domain layer, no you can’t use a dataset to model an important business concept, no you can’t reference this entity without going through its aggregate root first. This friction is what makes DDD effective — it gives traction to your OO code.

Life inside an Aggregate Root, part 2

In part one I talked about how entities have reference their parent aggregate root. Today I will talk about how new entities are added to the aggregate. Let’s have a look at the spec again for my example training system:

A Training Programme is comprised of Skills, arranged in Skill Groups. Skill Groups can contain Sub Groups with as many levels deep as you like.

Here’s our original code for adding Skill Groups to a Training Programme:

SkillGroup subGroup = new SkillGroup("First Aid", programme);programme.Add(subGroup);// add skills to subgroup etc

There are three things wrong here.

1. We’re breaking aggregate root boundaries. Skill Groups can only be constructed against one Training Programme, but can be added to as many Training Programmes as you like via the Add(SkillGroup) method.
2. Anemic domain model: Training Programmes and Skill Groups are just dumb containers here. The actual logic is being performed in the application services layer.
3. The application services layer knows too much about Skill Groups (how to construct them).

Rule #5: New objects inside the aggregate are created by existing objects

These sorts of problems can be avoided if we move the responsibility for creating Skill Groups to the Training Programme itself. The new keyword is a bit of a smell here — as Udi Dahan recently stated in a blog post, customers don’t just appear out of thin air. Let’s flip it around:

SkillGroup subGroup = trainingProgramme.AddSubGroup("First Aid");// add skills to subgroup etc

Now the Training Programme knows about creating and adding Skill Groups, and can hide away any factory construction or injection required to construct them. It also eliminates the situation where you could add the same Skill Group to multiple programmes:

SkillGroup subGroup = new SkillGroup("First Aid", programmeA);programmeA.Add(subGroup);programmeB.Add(subGroup); // what happens now?

Much better!

One of the projects I’m involved at work in is slowly migrating from classic ADO.NET to NHibernate. However, with around 2,200 stored procedures and 30 mapped classes, there is some overlap that cannot be avoided: a number of tables are written by one side but queried by the other.

For performance, we want to use NHibernate’s level 2 cache as much as possible. When rows in the underlying table are changed outside of the NHibernate session however (e.g. by a stored proc), the L2 cache needs to be flushed so it can repopulate with the new updated values.

SysCache2 is a drop-in cache provider for NHibernate that supports SqlDependencies, a SQL Server feature that notifies our application when data changes. It’s pretty easy to set up, but I found mine falling over immediately with the following error:

System.InvalidOperationException: When using SqlDependency without providing an options value, SqlDependency.Start() must be called prior to execution of a command added to the SqlDependency instance.

This isn’t mentioned in the documentation for SysCache2, and there’s not much on Google about it, but as the error message suggests, all you need to do is call SqlDependency.Start() at some point when your app starts. For example, in a web application, you can simply chuck it in global.asax.cs, before you configure the Session Factory.

public class Global : HttpApplication{    protected void Application_Start(Object sender, EventArgs e)    {        SqlDependency.Start(Config.DefaultConnectionString);        // create SessionFactory, set up container etc    }    protected void Application_End(Object sender, EventArgs e)    {        SqlDependency.Stop(Config.DefaultConnectionString);    }}