Layer SuperType: The Entity Base Class

Before we start of creating the domain objects, lets first create the base entity object. As discussed before, an entity is something that has an identity. This would be our layer supertype because this class will be inherited by all our domain objects that needs to have an identity.

namespace DDDBlog.Infrastructure.BaseClasses
{
    using System;
 
    public interface IEntity
    {
        int Key { get; }
    }
 
    public abstract class Entity : IEntity
    {
        private int key;
        public int Key
        {
            get { return key; }
        }
 
        protected Entity()
        {
        }
 
        protected Entity(int key)
        {
            this.key = key;
        }
 
        public bool Equals( Entity other )
        {
            return Equals( this, other );
        }
 
        public override bool Equals( object obj )
        {
            return Equals( this, obj as Entity );
        }
 
        public static bool Equals( Entity obj1, Entity obj2 )
        {
            if ( Object.Equals( obj1, null ) || Object.Equals( obj2, null ) ||
                obj1.GetType() != obj2.GetType() )
                return false;
 
            if ( ReferenceEquals( obj1, obj2 ) ) return true;
 
            return obj1.Key == obj2.Key;
        }
 
        public override int GetHashCode()
        {
            return Key.GetHashCode();;
        }
    }
}

The Entity base class is defined in the Infrastructure layer as the definition of entity is not part of the domain itself but it will be used by the domain. As you can see the Entity class has a key property which would be used as an identity. Also I am taking the key to be integer for simplicity. I have also implemented the equality comparison on the entity object. This is used to compare the entities.

Entity Tests

Now lets see some tests on the Entity class. A thing to remember is that in TDD, we would have to write the tests firsts and then come at the object.

namespace DDDBlog.Tests.Infrastructure.Tests
{
    using DDDBlog.Infrastructure.BaseClasses;
    using Xunit;
 
    public class FakeEntity : Entity
    {
        public FakeEntity()
            : base( 0 )
        {
        }
 
        public FakeEntity( int key )
            : base( key )
        {
        }
    }
 
    public class EntityTests
    {
        [Fact]
        public void Can_Create_An_Entity()
        {
            var entity = new FakeEntity();
            Assert.NotNull( entity );
        }
 
  [Fact]
        public void Newly_Created_Entity_Id_Should_Be_Zero()
        {
            var entity = new FakeEntity();
            Assert.Equal( entity.Key, 0 );
        }
 
        [Fact]
        public void Two_Entities_With_Same_Key_Should_Be_Equal()
        {
            var entity1 = new FakeEntity( 21 );
            var entity2 = new FakeEntity( 21 );
 
            Assert.Equal( entity1, entity2 );
            Assert.Equal( entity1.GetHashCode(), entity2.GetHashCode() );
        }
 
        [Fact]
        public void Two_Entities_With_Diffrent_Key_Should_Not_Be_Equal()
        {
            var entity1 = new FakeEntity( 21 );
            var entity2 = new FakeEntity( 3 );
 
            Assert.NotEqual( entity1, entity2 );
            Assert.NotEqual( entity1.GetHashCode(), entity2.GetHashCode() );
        }
 
 
        [Fact]
        public void Reference_To_Same_Entity_Should_Be_Equal()
        {
            var entity1 = new FakeEntity( 21 );
            var entity2 = entity1;
 
            Assert.Equal( entity1, entity2 );
            Assert.Equal( entity1.GetHashCode(), entity2.GetHashCode() );
        }
    }
}

AggregateRoot And IRepository<T>

Along with the Entity base class, we also need a repository base, and a way to mark an entity as an aggregate root. These are shown in the following snippets

namespace DDDBlog.Infrastructure.BaseClasses
{
    public interface IAggregateRoot : IEntity { }
}

namespace DDDBlog.Infrastructure.Repository
{
    using System.Linq;
    using BaseClasses;
 
    public interface IRepository<T> where T : IAggregateRoot
    {
        T FindBy( int key );
        IQueryable<T> FindAll();
        void Save( T entity );
        void Delete( T entity );
    }
}

As you can see our Aggregate root base is just an interface that inherits from IEntity. This is done because a repository is ( should be ) provided only on the Aggregate root. You can read a bit on Aggregates and Repositories here.

Now that our base classes are ready, we can look at the domain objects of our sample application, which I will be talking about in the next post.

You must know that, I am by no means an expert in DDD, TDD. The code shown above might be wrong as I am just stepping into this part of the world. Please leave a comment/ suggestion if you find something to be wrong or if it could be done better.

Setting up the project

Lets create the project structure as shown below.

DDDBlog.Domain : Domain layer is where the Plain-Old CLR Objects reside. These POCOs are entities that form the domain objects for our project. This layer would also contain the repository interface declarations for the domain objects. From a DDD perspective, the Domain layer should be unaware of persistence ( Persistence Ignorance ), so this layer will not have references to the Persistence layer

DDDBlog.Infrastructure : Infrastructure layer provides the bridging for other layers involved in the application. This layer will be used by all other layers. This layer would contain all the base classes required for all other projects. This layer would also define the top level repository interface. I am not sure where the mapping files should fall under this layer or the persistence layer, but for now I think I will go with this layer.

DDDBlog.Persistence :  This layer would contain the actual data access code. Here I will write the actual implementations for the repositories.

DDDBlog.Tests : This layer consists all the tests for all the layers. Its not necessary for us to have single test layer. We can add individual test layer for each of the layers in our application. I however am going with a single test layer.

DDDBlog.Web : This is the web presentation layer for our application.

Tools and libraries used

ASP.NET MVC – Used for the presentation layer. I had thoughts of using Monorail, but preferred ASP.NET MVC as it has come a long way from the CTP’s and I think its pretty good as of now.

NHibernate and FluentNHibernate – These are used for persistence and for the mappings.

StructureMap – This is used for Dependency Injection.

xUnit.Net – This is used for unity testing.

MoQ – This is used for mocking.

In this post we have seen how to layer our application and the tools/libraries that’s needed for our project. In my next post we’ll start coding the base classes for our application.

Test Driven Development

TDD could be told as an approach in development, where we are writing tests to know the area for which we are building the software. Tests written during the development phase helps you in understanding the domain, and, after development tests helps us document that system. Following are a few things about TDD that I have understood

The Steps

1) We write a failing test. We have to identity whether the test is testing what is intended in this step.
2) We make sure the test written in step 1 passes.
3) We refactor the code written in step 2.

We can also segregate a single test into 3 sections viz. Arrange – Where we setup everything that is there to test, Act – We do everything there is to do with the test, Assert – We check our assertions to be true or not.

But its hard to test

There are certain areas that are hard to test, like UI ( Its all the more reason to split the UI aspects from the domain model ). Then there is the database which makes it even harder to test. Why? because working with actual db is cumbersome, we have to maintain the state of database for every run of the test. This could be done for integration test, but while in development stages, stubs or mocks could be used, and lastly there is the code of the tests themselves which we’ll have to maintain, but that should be ok, because the tests helps a lot in doing maintenance work.

Stubs and Mocks

There will certain areas in our development which when tested might be too slow or difficult to setup for example the UI or the database operation. To overcome these difficulties we can use stubs or mocks.

A stub is a light weight implementation of a real object. It is a way to setup the expected values that can be used within the test. In tests stubs we create a class that impersonates the actual class that we have to test. For example if we are to test a class that does database operations, we create a stub class that is free of the database and use this stub class in our tests. The thing to note here is that we are testing the database operation methods and not the actual database call and also we provide the input and the output via the stubs. A mock is also an implementation of a real object, but unlike stubs we can set our expectations in mocks on how it should be used and it also provides self validations on the expected results. Mocks are usually created frameworks.

You can read about the differences between mocks and stubs here

I will be writing more on TDD as I dwell more into the development of the sample application.

Aggregates and Aggregate Root

In a software there can invariably be many objects, and some of these objects are bound to be related to each other in some way. These objects that are related to each other are known as aggregates and an aggregate root is the object that holds them together. Aggregate root is always an entity. Say for example in a blog application a comment would be related to a post. So post and comments become an aggregate and post becomes the aggregate root as there cant be any comments without a post.

Aggregates are to be considered as one unit with regard to any data manipulation and these aggregates can be accessed from outside only through their aggregate root. This mechanism of accessing the objects only by the root helps in maintain data integrity as individual objects can not be changed directly.

Factories

When we are to create an aggregate or an entity, it might become too complex for us to create it in the constructor of the root entity. This is where the factory fits in. The role of the factory is to create an object. These factories are helpful when we are creating an aggregate because when the root is created, all the associated aggregates under the root is also created for us.

The process of object creation by a factory needs to be atomic. This is required because we don’t want to have an aggregate root created without creating the the associated aggregates which might leave the system in a unstable state.

You can read about the factory pattern from my earlier posts here and here.

Repositories

In any application, domain objects will need other objects for their operation. So these domain objects could be made to hold references to the other needed objects. If we are to give the  domain objects this behavior of maintaining references, then they become tightly coupled as they are holding on to all the references they need at any given time.

This could be avoided by the using repositories. Repositories are used to maintain the references of objects. Using repositories the domain objects are not involved in maintaining the references to the needed object, instead they can get it from the repository.

Repositories are just a storage place where we can store the data and retrieve it later. These repositories are based on strategy, meaning,  based on different strategies it may use different storage locations for different type of objects.

Next Steps

What I have covered in this and my previous post is just the starting point of DDD. There are still many factors into DDD, which probably I will be writing about as I build the application.

In my next post I will be writing about the project structure, why the project is split as it is, and what is the role of each layer.

DDD could be called as a methodology or a set of patterns which help us in developing a software pertaining to the domain. Here what domain means, is the actual system for which we are building the software. DDD is not breaking away from the core Object Oriented design principles, but to utilize them in the right way. There are many aspects in DDD which we need to consider when building an application. Following are the aspects and their brief explanations from what I have understood.

The Ubiquitous Language ( UL )

Developers when building a software tend to wholly dwell into the technical aspects of the the application unlike the domain experts who have an extensive knowledge of the problem domain rather than the technical solution for it. When a domain expert is sharing his expertise, he will using a lot of terms that may not be understood by the development team, thus brining in a communication gap between the two. 

Ubiquitous language in DDD addresses this communication gap between the developers and the business experts. The function of the UL is to connect all parts of the design which would have been led by the domain experts and developers need to follow this. The key point in UL is to identify the the concepts which defines the domain and come up with common terms for those.

Layered Architecture

When we develop a software in the OO way, a lot of UI and data specific code is mixed with the domain objects. The problem with this is a change in the UI or the data specific code might change the domain behavior and tracking these changes becomes difficult because to arrive at the domain behavior we’ll have to check the UI/data components which changed the behavior in the first place.

The solution for this is to segregate the software into layers such that the layers are loosely coupled and one layer being dependent only on the layers below it. The main criteria in the layering is to free up the domain objects from the UI/data specific logic.

I will talk about the different layers in a future post where I’ll come up with the initial project structure for the blog application.

Entities and Value Objects

Entities and Value Objects form the underlying principles in DDD. Entities are objects which have an identity and this identity is maintained throughout the lifetime of the application. The identity can be represented  differently in different applications, for example an store application can have an Customer entity which can be identified from the CustomerID.

Value Objects are objects that have no identity, meaning that we are representing an object by its attributes alone. Usually Value Objects acts as a part of an entity, for example the Customer entity can have an Address Value object which in itself cannot be identified other than belonging to a customer.

Services

When developing a software there are certain behavior which might not fit into entities or value objects, meaning if we add these behavior into the objects then they might give a different meaning to the object, which was not intended. But in OO languages we would need an object to represent this functionality, These objects are declared as services. For example in a store application shipping a product to a customer can be declared as a service.

Services are interfaces which are used in performing some operations on the objects ( entities / value objects ). These operations are the ones that doesn't fit in the objects.

This is the the end of Part I. I will continue with the basics of DDD in my next post.

So I am going to start a “Learn as you build” series in which I build a blog engine using these technologies ( or methodologies ). This is not a full fledged blog engine mind you. This is a process of learning new things and blog engine is just right to start of with ( along the lines from this post). If you are looking for a full featured blog engine, you can have a look at BlogEngine.NET or DasBlog or SubText and many more I guess.

Along with these things I would also want to explore NHibernate which is an ORM ( another TLA!!! ) and MoQ ( a mocking framework ). Well I think I am getting into a lot of things, probably more than I can handle, but lets see where these things lead me.

I would appreciate any sort of suggestions that might help me in diving into these things.

More blogs to follow on these lines.