Leverage the concept of “state” of your entities

One of the interesting ideas found in Radical and other implementations of DDD architectures, is implementing properties of Domain objects in a slightly different way from the standard, using something like a dictionary to store values of properties. When we want to implement a property for a Domain class you usually end up with similar code.

   1: public String Property { get; set; }


   3: private string _fieldBasedProperty;

   4: public String FieldBasedProperty

   5: {

   6:     get { return _fieldBasedProperty; }

   7:     set { _fieldBasedProperty = value; }

   8: }

Both of them use a private field to store the real value of the property, the first one is a compact form  (I to not like it for Domain object because it gives you no control on state changing of the object), the second one is the standard code to implement a property with a Backing field. Remember that in OOP an Object is a composition of Code and Data and having getter and setter for properties give use control on the state of the object. Both of the above implementations are based on this concept and are widely used in all projects.

But we could adopt another approach to enforce the concept of state of the object, making the concept of state emerge from the implementation. We start defining a State class.


This class is used to store values indexed by property names and will used to maintain the state of all entities. Thanks to this class we can define a BaseEntity class to implement some basic functionality that we want to share between all classes.


The most important methods are Get and Set methods, used by derived classes to manage change of state of the object. If you want to implement a simple property in a derived class, you will write this code.

   1: class Post : BaseEntity

   2: {

   3:     public String Title

   4:     {

   5:         get { return Get(() => Title);}

   6:         set { Set(() => Title, value);}

   7:     }

   8: }

The syntax used is strongly typed, thanks to static reflection, and delegates to base class state management, in this simple example base class implements the INotifyPropertyChanged, but you can implement all the logic you want.

This approach is really interesting, because it does not prevent you from using any technique you use with the standard property and state management, but leverage the concept of state in a consistent way. With standard property implementation, state is scattered across various fields of an entity, an approach that is not really DDD oriented; using an explicit concept (and a specific class) to manage state leverage the concept of encapsulation in a more explicit way and can lead to interesting solutions.



Published by

Ricci Gian Maria

.Net programmer, User group and community enthusiast, programmer - aspiring architect - and guitar player :). Visual Studio ALM MVP

2 thoughts on “Leverage the concept of “state” of your entities”

  1. Hello,

    Congratulations for your blog.
    The other day you were talking about creating a “real world” sample of Domain-Driven Design implementation.
    I’m running a project (hosted on github) which is a PetStore implemented using DDD.

    Please, take a look at the project at: http://www.github.com/andreazevedo/petstore-ddd-csharp

    It is just starting, but you can have an ideia of what it will extend for.

    Feel free to coment and contribute.


  2. Thanks, this period I’m busy, but I bookmarked your link :) and as soon as I have time I’ll give it a look, I’m always interested in exchanging ideas with other persons. :)


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.