Implementing a Customer Search Service with DDD, BDD and the Entity Framework

I’ve been keeping an eye on the evolution of the Entity Framework since the early VS2008 betas, but it’s lack of POCO support in its V1 release really put me off, especially since this made it particularly awkward to use Test Driven Development (TDD). For me, the final nail in the coffin was its apparent incompatibility with Domain-Driven Design (DDD), or so I thought…

Jaroslaw Kowalski recently posted on his blog about a sample project published on MSDN that allows an adapter layer to be written (generated), which will translate between POCO objects and Entity Framework-aware objects. By doing this, an application service can make use of features like Change Tracking, Lazy Loading, LINQ Queries, and Shadow State, without interfering with our POCO objects. This allows use to create our Domain Model without being distracted by persistence concerns, and even better, our model can be created independently from our database schema.

As you can imagine, this has re-ignited my interest in the Entity Framework, but before I’m sold on the idea, I figured I’d put the sample to the test by trying it out with service implemented following DDD.

Where to begin?

The published sample project (currently on version 1.0.3 at the time of writing) contains some simple POCO classes based on the Northwind database. Some of these POCO objects may be considered to be Entities, such a Product or Customer, and some may be considered to be value objects, such as CommonAddress (which by the way is also immutable). What we are missing in  the example though  (for the purposes of a well-rounded DDD test) is some clear Aggregate Boundaries, some repositories to retrieve references to our Aggregate roots and Services to provide a cohesive set of operations to our client applications.

Assuming an existing Entity, such as customer, can be made the root of its own aggregate, and that we can easily define our own repositories* by writing our own implementation of an EFPocoContext (the code-generated context will have IEntitySet<T> properties for each of our entities, not just the aggregate roots, so is inappropriate for DDD), all that remains to be proven then is a service implementation.

*It’s also debatable whether a repository should return a result in the form IQueryable<TEntity> since this is only a query object, and not the result itself (see this post for further discussion on this).

The Task

What I’d like to do is create a simple Application Service that allows a client application to search for customers. I’d like to extend the simple CustomerSearchService featured here to include the ability to search on a wider set of criteria, and return a collection of search results. The criteria for the search may relate to the  customer itself, the customers order detail, or a combination of criteria. In fact, as a sample range of criteria, lets use those listed by Jimmy Nilsson in his book “Applying Domain-Driven Design and Patterns”:

We should be able to query for customers who:

  • Have a name with “aa” in it. (Hidden Marketing for a Swedish car company.)
  • Ordered something last month.
  • Have orders with a total amount greater than one million.
  • Have a reference person called “Stig.”

Since I also want this example to test the compatibility of the Entity Framework with “modern development approaches”, I will also be test-driving the development following (as closely as I can) to the style of Behaviour Driven Development (BDD). Typically in BDD, the words “Given”, “When” and “Then” are often used to help drive out the scenarios. The word “Given” describes the context of the test, the state of the SUT if you will. The word “When” represents the unit of work or action that you are testing. The word “Then” simply describes each result, or observation expected from the system. For the purposes of this implementation, I shall use the following scenarios:

WHEN searching for customers

GIVEN customers exist matching the search criteria

THEN records matching the criteria will be retrieved from the persistence store AND customer summaries are returned AND the search is successful

GIVEN no customers match the search criteria

THEN the search is unsuccessful AND the client application is notified that no customers match the provided criteria.


So this should give me a decent starting point to kick off from. Next time we’ll code up the unit tests for this and crack on with the implementation.


About craigcav

Craig Cavalier works as a Software Developer for Liquid Frameworks in Houston Tx, developing field ticketing and job management solutions for industrial field service companies.

Posted on October 8, 2008, in Behaviour Driven Development, Domain Driven Design, Entity Framework, Persistence Ignorance. Bookmark the permalink. 2 Comments.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: