Excellent post about CQRS by Udi Dahan

Udi Dahan has published an excellent blog post about Command Query Responsibility Segregation. This is a really interesting approach of software development, and I tend to follow that approach in my NetworkMonitoring system.

The power of patterns

The user interface is one of the most important parts of an application, at least for the end user. It is also the part of the application that will change a lot during the life cycle of an application. Sometimes I even think that you can just make some changes in the user interface and call it a new version of the product and users will be happy.
So to be able to change the user interface without much trouble is a must. But with a lot of applications I saw, this is not possible.What is the problem? The user interface contains to much logic.
This is a problem that many people had and there are some easy ways to solve this...
Patterns
When a couple of people found the same problem and a solution for it, we can call of a pattern. A pattern is just a description of the solution and not the solution itself, so most of the time you have to modify the pattern a little bit to make it work efficiently in your own situation.

A pattern we can use for our user interface problem is the Model View Controller (MVC) pattern.
In MVC we have the Model which is just the data that is requested by the user. The View is the actual form that shows the data from the Model and it will send actions from the user to the Controller. The Controller is responsible for giving the View the right data and update the Model. When the Model is updated it will send a notification to the View and the View will update itself.

Now  this is a basic and fast description of MVC and there are a lot more (and better) descriptions on the internet and in books ;)

The 'problem' I have with MVC is that the Model sends updates to the view and the view knows a lot of the Model. And I am not the only one, because there is an other pattern called Model View Presenter (MVP) which is basically a decoupled version of MVC. The Role of the Model is the same, but the View only shows data which it gets from the presenter, and it doesn't update anything by itself. The Presenter has a bigger role, whenever an action is performed it should update the data on the view. It could be frustrating, but it makes the view (user interface) easier to understand/change.
Changing the user interface
Using this patterns makes it really easy to change the user interface, we can easily make a new view and add it it to the Presenter. How these are coupled is basically a matter of taste. I tend to go for Dependency Injection, but it is also possible to give the Presenter a little more knowledge and let it create the view manually.
Although I am not sure about it because I never tried it, I think the MVC pattern family make it easy to change from a desktop application to a web application. There will be some changes in the infrastructure, but in the presenters and the models there shouldn't be much differences.
Testing the presenters
Testing the user interface is difficult, and testing logic in the user interface even more difficult. Using the MVC pattern makes it pretty easy to test at least the most of the logic since the logic is inside the Presenter. We can create a simple version of the view to test whether information is send to it and we can use it to see if the events are working.
So the only not tested parts of the system are the actual views, these should be tested by humans because automated tests will be to complicated (although there are tools who can do this...)
Conclusion
When you have a problem and don't know how to solve it, it is great to be able to find a pattern that describes a possible solution. The problem is that you should have seen the pattern before you know that you can use it. That was basically the purpose of this post. I introduced you to the problem of a fat UI and I mentioned a pattern that could solve the problem. But there are a lot more patterns you probably wan to know about. Therefore I want to redirect you to a few sites:

• http://martinfowler.com/eaaDev/  - Application Architecture patterns, very interesting to read
• http://sourcemaking.com/design_patterns - a site that describe some basic design patterns
• http://www.dofactory.com/Patterns/Patterns.aspx - an other site describing basic design patterns

To inject or not to inject, that is the question

When trying to implement the specification and implementation for scheduling a check, I had the problem of what method to use for sending the event.
There are basically two options:

1. Inject a Bus
2. Use a static/well known object for sending the event.

Lets take a look at both options...

Inject a bus

When Injecting a bus (or an other service) the Host will need a variable/field that holds the implementation of the service. Somehow the real implementation should be injected into the object. Normally we will do that by using a framework like structuremap or some other Dependency Injection framework.
But we have the problem that Host is an Entity which we will not instantiate ourself, but we ask our repository. So there will be another place where we need to inject the right service and I think this will lead us to duplicate code.

Use static object

Using a static object would be much simpler. We have one object that sends all events to the right place. How the event handlers are registered depends on the architecture of the application, but basically this will be done via an Dependency Injection framework. This method is explained more deeply by Udi Dahan.

Conclusion

Injecting services into entities is just to complicated and in my opinion should be avoided.
Using static classes as services should also be avoided, because it will make testing more difficult.

So what do we use? I will choose for the static class, because it only routes the actual events to the right handler, it will be easy to implement and it will be easy to use it in tests. Other services should be non static classes so that it follows the normal object oriented philosophy.

The host in charge or How to design software the good way.

Software design is something that can be really challenging. This becomes more clear when you are working on a project now and than, or have some very complicated software.
In the last topic I talked about the challenge of defining the scheduler and what it should schedule. I thought it was a good and easy point to start with, but it is not. I think by starting with the scheduler I want to make it much to generic and I don't want to be to generic, I just want it to do what it should do.
To identify what it should do I have to start somewhere else.

The Host.

Within NetworkMonitor hosts play an important role. A host is a network device with a networkcard and an network address.
The state of the host can be checked and set from the outside. The host itself is responsible to notify others that a new check should be scheduled, but the user should be able to schedule a check manually as well.

This above text will leas us to the following design:

The SetState and ScheduleCheck methods will have parameters, but I don't know them yet.
The idea is that when the SetState method is called, the ScheduleCheck is called automaticly.
The ScheduleCheck will fire an event (ScheduleCheckEvent) to schedule the check. The event will contain all the necesary information for others to get the right host, the right check and the right time to perform the check.
Since the host has a public ScheduleCheck methode, the user can also schedule the check whenever he likes.

The Tests

Since this is a learning project I want to start using a Test first approach. This means we start with writing tests and then write the code to let the tests pass.
I am going to use specification style testing which means I write specifications/stories about what I need to test. Here are my specifications for the Host:

Given: an Host
When : ScheduleCheck is called
Then : a ScheduleCheckEvent is raised

Given: an Host
When : the status is set via SetStatus
Then : then a ScheduleCheckEvent is raised

I tried writing specifications before, but I found it always difficult to do. These specifications are as simple as can be. The reason for this (I think) is that I want to test less than before, or made things to complex.

ok, but that is not code.. I am going to use MSpec which is a .NET project for Behaviour Driven style testing.

public class When_scheduling_a_check
{
   static Host hots;
   Establish context = () => { host = new Host("10.1.1.2"); };
   Because of = () => { host.ScheduleCheck(DateTime.Now); };
   It should_have_raised_a_ScheduleCheckEvent;
}

public class When_setting_the_status
{
   static Host hots;
   Establish context = () => { host = new Host("10.1.1.2"); };
   Because of = () => { host.SetState(State.Ok); };
   It should_have_raise_a_ScheduleCheckEvent;
}

All that I have done here are writing the When (Establish context) and Then (Because of). The actual test is still pending.
The funny code (() => {};) is part of the .NET syntax and are called lambda expressions. This makes it possible to put functions/methods inside a property to be run at a later moment.

Well thats all for today. I will have to implement this first before I continue :)

Scheduler, what to schedule?

I am thinking about the scheduler part of my NetworkMonitor. On of the things I want to do in the NetworkMonitor is to use a service layer. A service layer is a thin layer between the actual application (executable / user interface) and the domain. and it provide the supported scenarios. In case of Commands Query Seperation, it also provide the commands and their handlers.

Back to the scheduler part... I want to have a SchedulingService which provide all the possible operations for the scheduler. Since I want to use the YAGNI (You Aint Gonna Need It) approach. I only have two methods for this service:

• Schedule something
• Do something with the Scheduled things

As you can see this is really vague... What do I need to schedule? Do I schedule Events? Do I schedule Commands? (here commands are a domain specific thing) Do I schedule System.Action?

At this point I just don't know... I think it really depends on how generic this scheduler should be... Should I be able to schedule tasks that are not domain stuff as well? or do I choose to schedule only domain specific stuff.

The solution
Well, since I want to be YAGNI, I think I decide to schedule only domain specific tasks. When a task is scheduled and it is time to perform the task I will fire an event to let some other class know that it should be performed.
Conclusion
It is a good thing to think out loud... You get some solutions that way.

Commands and Events

In my last post I ended with talking about sending messages between bounded contexts. In this post I want to describe how to do this, but I also want to talk about a new thing I want to try out. It is called Command and Query Responsibility Segregation (CQRS).

Please leave a message to tell me if you understand it or not?

With CQRS you are basically splitting the commands from the queries (Inserts, updates, deletes from the selects :)). This means that we can optimise how we show data on the user interface and how we handle changes.

From the user interface we send "Commands" to the domain. These commands will modify the aggregate roots and save the changes. These changes are translated into "Events" which are saved. When we want to get our aggregate root, we simple have to playback all the events to get our state. This means we have a nice log of what has happened with the object.

An example

"Ok, sounds nice, but how does it work?" you may say.. Lets look at a simplified example:
The user wants to create a new radio program into the system. After clicking on the "New" button, the UI does something like:

_commandBus.Send(new CreateRadioProgramCommand(Guid.NewGuid(), _programName));

In the domain we have a CreateRadioProgramCommandHandler class which will create a new RadioProgram object and save it to the Repository.
While creating the RadioProgram a CreateRadioProgramEvent will be created. This event will be saved in the database and will be published. By publishing the event the event can be used to update the query cache so that the user can find the RadioProgram in the user interface.

Updating the radio

Now that we have a Radio Program, the user can use the user interface to change details of the Radio Program. So when we have changed things, the UI does something like:

_commandBus.Send(new ChangeRadioProgramLanguage(_id, "Dutch"));

The ChangeRadioProgramLanguageCommandHandler will ask the repository for the correct radio program. The repository will get all previous events and use those to construct the Radio Program.
Then the Language will be changed and the Radio Program will be saved.
This causes a new event, LanguageChangedEvent and this event will be published so that the UI cache will be changed.

Communicating with Bounded Contexts?

At this point I am not really curtain how the communication between Bounded Contexts can be established. I think it could be both "Events" AND "Commands" or "Events" that are leading to "Commands"

NetworkMonitor: my new view of the structure

During the last few weeks I have been reading a lot about software architecture and how other people do things. I found out that it is very easy to create a publish/subscribe system that makes it easy to send messages from one place of the system to somewhere else. I see it as an ideal method to communicate between Bounded Contexts.
With this knowledge I was thinking about how I can structure NetworkMonitor in a loosely coupled way.

• Scheduler
• Command runner
• Host/Service state

Scheduler

The scheduler has the important task to keep a list of scheduled items, this can domain specific things like running commands to check the state of host/services, but also application things like do a log rotation.. The Scheduler can be very generic so that it supports a lot of different items.

Command runner

The command runner will do the actual actions for getting the state of hosts/services. It will run the command and wait for the response, the response will be parsed and the state of the host or service will be set.

Host/Service state

The state of hosts or services can be very simple, but when the state changes to an unexpected state, several things should be done. The Host/Service state has the responsibility to schedule new commands based on the current state, and will be used to show the user the state information.

The missing link

The three subsystems are very different from each other, but they should still communicate with each other. The problem here is how do they communicate.
Before we can answer that we should know where each part is in the system.
I see three possibilities:

• They are all in the same application
• They are in different applications on the same computer
• They are on different places in the network/world

When we choose for only the first option, it will be easy. We can use simple event (like windows messaging or .net events), but this won't work when we need to support the other solutions.
The other two solutions need some kind of messaging system over the network/memory. The same method we can use when we have all the systems in the same application.
What I am thinking about is a Publish/Subscribe pattern.
In short the pattern has one class where all publishers post messages to, and everyone that want to respond on a message, adds(subscribes) itself as listener to that same class. When a message is send, the class will go over every listener and post the message.
How this is done over a network I am not sure yet, but I think it should be possible.

That it for this moment.. I've got a lot of ideas and will try to implement them. But first I have to do some work...

Resources I find usefull

in the past two or three years, since I am graduated, I am on a constant search for better and new ways of doing things. Most of the information I find in blogs, articles and sometimes in books. (I am not really networking yet, shame on me...)

Here is a list of resources I found useful in no particular order:

EBook:
Foundations of programming: I think this is a collection of blog posts that describe a lot of basic principles.


Books:
Domain Driven Design by Eric Evans: this is a complex abstract book, but once you read it a few times, it is a valuable source.
Applying UML and Patterns by Craig Larman: a good book to get into "modern" object oriented software development. Sometimes I think there is to much information in the book.
Patterns of Enterprise Application Architecture by Martin Fowler: The latest addition in my collection, it describes a lot of patterns that could be used in applications. I like to have a book where I can find the information I need.
The Pragmatic Programmer: This book gives a nice view on what programmers are and how to use the tools they have.

Websites/Blogs:
http://www.infoq.com/: News, Articles, Presentations and ebooks about software development. for the ebooks registration is required...
http://dddstepbystep.com/: information about Domain Driven Design.
http://codebetter.com/
http://devlicious.com/
http://www.lostechies.com/
http://www.udidahan.com/?blog=true
http://martinfowler.com/bliki/

Bounded Context

Sometimes aspects of a domain can have slightly different meanings within different parts of that domain.
When we talk about a radio program this can have different meanings for different people and applications. For one program it means something that a producer makes and that has content like talk and music, in an other part of the organisation it could just mean a file that should be transferred to the right place, yet another part of the organisation sees it as something that should be aired.
Still they are all related.
Of course we could put them all in the same domain, but then people don't understand the software completely. By putting them all in a separate domain, a bounded context, it will become more clear how relations go. This way the people who air the radio program don't have to know that that same radio program has a relationship with a producer.

Another reason to introduce bounded contexts is when the domain is getting to big and to complex. It will pay of to put split the domain in multiple bounded contexts.

But there should be a way to connect these bounded contexts. This can be done in several ways. One way is to write a layer between both domains that convert from one domain to an other.
An other way is to use messages and ask for information. This method I will explain in more detail in the next post when I talk about a new idea for the network monitor system.

Domain Driven Design and Time based tasks

In one of the projects I worked on, there were a lot of actions that happened at specific times. At midnight the logs would be rotated, an hour past midnight things where rescheduled and checked. at a specific point in the schedule, that item was processed.

With Domain Driven Design it is not obvious how to implement this. Normally we don't have timers in the domain. First of all it is not easy to test timers and their events and secondly, it is not the responsibility of the domain to get the current time and initiate actions.
So how can we do it then? What I am about to write is something I didn't try, but it basically 'popped up' in my head.

A timer is in terms of DDD just an external service. Every time it needs to fire an event, or the time is changing, it will send a message to the domain. So basically it is like a heartbeat. (During my graduation we had a program which controlled a robot, and that program also had a heartbeat to let the robot make decisions...)

In the domain we can have classes like Schedule,which has a method that can receive the current date and time. When this method is called, the schedule will look to the scheduled actions that should be run at that time and will fire events to initiate the actions.
These events can go from one domain to another (bounded contexts, did I already speak about that? if not I will try to do that soon), or from one application to another. We can also store the events that come in and go out, so that we have a history of what happend.

How do the events look like? I think of them like normal objects that contains information about the actions.

I understand that the above is a bid abstract, but it came to my while I was reading different articles about Event Sourcing, Command Query Seperation and other things over the last view days, and now I had the feeling that I should put this in some sort of writing to remember it.

Domain / UI speration

On the current project the decision was made to use domain objects directly in the user interface. It seemed to be a good idea at first, it made a lot of code unnecessary, but there where some things that were not solved nicely.

DataBinding

An option that we have in .NET is databinding. this means that we can bind properties to controls and let the control update it self when a specific property is changed. There are also collections that can be bound to objects and that can react to changes from their items.

In our domain we basically have items which have a description and a price. Each item can have subitems (but this isn't necessary) and when there are subitems, the price of the item is the total of the subitems.
The way the domain was set up was that the total price was calculated as soon as the list was changed. We responded to the ListChanged event, calculated the total and set the Price property.

This worked fine, the User interface was getting changed and everybody was happy, but we didn't have any persistence at that moment.

Persistence

When I was implementing/configuring the persistence for our domain, I came across a few problems. First of all the BindingList<> object we used for the subitems was not supported by the framework we use (NHibernate), so we had a choice to make: Implement a custom collection or add extra properties for the BindingList (one exposing the BindingList<>, an other exposing a normal IList<> which could be handled by NHibernate). We went for the custom collection. this went fine for a lot of things, except for the price totals.
When an Item is loaded from the database, a few things happen:

• an Item object is created
• a list with for subitems is created
• eventhandlers are coupled to the list
• NHibernate sets every property that is mapped, including the list

The last step was deadly for our domain logic. at the moment the list of subitems is set, the event handlers still refer to the old list. This means that when a subitem changes or subitems are added/removed the event handler will NOT pick this up and the total price will not be changed.

Solution

The solution is pretty straight forward, but is a change of thinking. Instead of setting the total price, ask for the total price. So we do "SubItems.Sum(x => x.Price)" in the getter of Item.Price. This way we eliminate the need of a BindingList and event handlers and we can save and load everything.
This gives us another problem. A grid with SubItems will not automatically refresh. This can be solved by add a special Item to the view, ItemView or ItemPresenter or ItemPresentation or whatever, this class should have the logic to drive the User Interface and tell the user interface to change when something important happend. Because this class needs domain logic I did make a subclass for this and I map all the values from one class to the other. (in other cases I just change/use the base class directly, so instead of using a subclass it is a gateway)

This seems to be a lot of extra work, and it is, but I think it is worth the trouble and there are a lot of libraries that can ease the pain. (such as automapper which can map two objects to each other by copying all the values of the properties from one object to the other)
Adding these View classes will make the actual UI code easier to read (and write)

I will try to investigate more about UI patterns, and hope to write down more.

Avoid flexibility!

On the project I am working on, the software should be able to do anything. It should be possible to make all kind of transactions, it should be possible to ad an unlimited amount of Mortgages (and to pay back an unlimited amount of Mortgages). The whole application should be unlimited.
When I came into the project, there was already a basis for this. The user is able to combine all kind of inputs (Transaction, ToPay, ToReceive, and some other things) all these inputs can have an unlimited number of items.
There is a difference between "design time" and "runtime". Design time is where the administrator can create models, by combining those input-designs and creating default items for them.
The runtime is when the design is used to make an invoice. The input-design becomes an input and the default item an item. I really liked this idea, but after some time things where getting difficult. One of the things is that inputs have dependencies, and different inputs have different behaviour for these dependencies.

In Holland we have some kind of tax which needs some money from a transaction and money from a Leasehold. But how do you know which transaction belongs to which leasehold? Ok we only take one leasehold and combine all the transactions, that is enough for this tax. But how do other inputs work with dependencies? and how can we make it as flexible as possible?

This is why I want to say, stop with this stupid flexibility! it only cost valuable time to implement things and make it possible for the user to do everything!

Flexibility is good and in software development it is very useful to have (without flexible code it gets difficult to add features to the code). But please stop asking for "everthing should be possible"-applications...

It's all about the language

In software development it is very important to name your classes, methods, properties, etc in the right way, so you can find them quickly. It is also important to name them the way you talk about them, this became very clear to me during my current project.

The project I am currently working on is a project for solicitors. The project is only focussing an a relative small part, namely invoice creation.
Solicitors are working with cases (at least here in the Netherlands they are). For such a case they create an invoice. In this new software they want to choose from several types of things, when they are involved in selling/buying a house, they want to choose that specific invoice model and when they are involved in setting up a will, they want to choose that invoice model.
Each model has some elements. In case of selling/buying a house there is a transaction, some tax and other important stuff.

This is really simple, but when I stepped into the project, there where not such types. Instead there where some types called Case, CaseComponent and CaseComponentAspect. Every day there was a discussion between the developers and the domain expert about what the meaning of these types where. At some point the developers made a "conversion list" telling what the domain expert said and how they called it.
According to the domain expert these things where called: Case, InvoiceModel and InvoiceElement. This is exactly how I expected it to be and soon I pushed the other developers to change it. After the refactoring there weren't any discussions about the naming and everything is clear to everyone.

Therefore, please choose your type names carefully, so that every member of the team knows where you are talking about...

Configuring a monitoring system

At work I am working on software where the administrator have the possibility to build models using building blocks. These models can be used to build invoices. The way this is done can be used in other projects as well.
In my network monitoring system it should be possible to easily configure the network layout.

Definitions

The first thing I am thinking about is to make definitions of the building blocks for our system. So we get a definition for host, service, command and probably some others as well.
So we will have something like the following layout:

It is no really useful to have the definitions when it is not possible to tell the user which definitions are available. This can be solved by creating classes for the definition types. All these classes do is holding a static instance of themselves, hold the name of the type and create a new definition of that type. Since the definition type can not be changed by anyone and we need it to create the real definitions, it is not necessary to construct them our self, that's why we use the singleton pattern here. Another advantage is that we can use this instance to show it to the user as well.

Using the definitions

We can now make a user interface to make it easy to create the definitions and configure them. Therefore we need some extra patterns. Let's say our user interface will look like this:

The buttons at the top are used to select the type of definition. When ever a type is selected a new definition will be created. We use a Factory method for this. (factory method: a method that has the logic to create an object) The created definition will be added to the listview with definitions.
The window on the right is a property grid, which can be used to change the properties of an object, so whenever one clicks on an item in the listview, the property grid will show the properties which can be changed.
At this point we don't add the definitions to the repository, because
we want to be able to cancel the changes we made. When we push the Save
button, we register all changes to the Repository and the data will be persisted.

Conclusion

Using this method it is pretty easy to configure a whole network. (Why didn't I think of it sooner...) Using this configuration is also pretty simple. But I will leave that for another post :)

Bussy with personel life

It has been a while since I have been writing something on this blog. This is mostly due to things that are currently happening in my life. Last month I got the key of my new apartment and there is much to do, besides that I have to prepare for a wedding (my own wedding ;)) and I also have to work.
The good thing is that I am learning very much at work about Domain Driven Design and different programming techniques. At the moment I try to put something in practise that I have learned at work and I am writing a post about it. I hope the post will be ready next week.

Factories and Repositories

In my last post I talked about entities, the domain objects that have an identity and a life. In this post I want to talk about the management of the lifetime of entities. We start at the beginning.

Creation of objects

Creation of objects could be very simple:

new RadioProgram(); // C#
or
RadioProgram.Create; //Delphi

But what when it is not that simple and there are a lot of extra dependencies and relations that should  be connected? We can use the Factory pattern for this purpose. When we use a Factory we use an object to create another object.

class RadioProgram
{
    public RadioProgram()
    {
    }

    public RadioStation { get; set; }
}

class RadioProgramFactory
{
    private RadioStation defaultStation = new RadioStation("DutchRadio");

    public RadioProgram CreateProgram()
    {
        RadioProgram program = new RadioProgram();
        program.RadioStation = this.defaultStation;
        return program;
    }
}

In the code above I create a RadioProgram which is only valid when there is a radio station assigned to it. (actually, normally this is not needed and added later, but I lack the fantasy to think of an original example). So to get a valid RadioProgram we will have to create a RadioProgramFactory and call the CreateProgram method.

Repositories

Now that we have a nice domain object, we need a place to store it. There are several places where we can store objects. We can store them in databases, in XML files, in binary streams and in a dozen of other places. But why should I (read the domain) should care about storage or persistency? We shouldn't care about it. In Domain Driven Design we create the domain with Persistence Ignorance in mind. The objects in the domain don't have to know when, where, why or even if they get persisted. The only thing we can/should do in the domain is to register the domain objects to Repositories.
A repository can be a big thing. We can use it to store objects, we can use it to find objects (in several ways) and we can use repositories to delete objects. But in the domain we won't actually do these things. Hmm. that is confusing.
OK, on one site I say that the domain should be able to talk to the repository. On the other side I say, the domain should not know anything about Persistence. To solve this problem we can say the following: The domain should create the definition (an interface) for the repository, it will tell what the domain expects from a repository.
Outside the domain we can have multiple implementations of a repository interface. With one implementation we talk to a legacy database, with another implementation we talk with a newly created database. During run-time we can say to the application which implementation it should use. This technique can be used for other things as well and is called Dependency Injection (although it has also some other names).
So how does a repository looks like? Here is an example of the interface that is in the domain:

public interface RadioProgramRepositoryInterface
{
    void Add(RadioProgram program);
    void Update(RadioProgram program);
    void Delete(RadioProgram program);

    RadioProgram GetProgram(string programName); // programName is the identifier in this case.
    List<RadioProgram> All(); // Get a list of all available RadioPrograms.
    List<RadioProgram> GetProgramQueueForStation(RadioStation aStation); // Get the program queue for a specific station.
}

So basically you can do anything in a repository that you can also do with a database, but the different is that you don't know what kind of database it is, it could also be an In-Memory stack or some files somewhere on the Internet. The last method is used to get a specific list of radio programs (programs that are queued for a specific station) This is a pretty easy selection, but it could be possible to get very complicated selections. In that case we can use Specifications or some kind of Query language. I will not go further into those topics, because they are to complicated to handle in short and I don't have any experience with them.

Dependency Injection

Before we can really use the persistent specific repositories we need to be able to find out which repository we need to use. This part of domain driven design can be difficult and it is easier said than done.
In my current project we maintain a list of interfaces and implementations that can be injected. (ie. RadioProgramRepositoryInterface - MemoryRadioProgramRepository, where the later is the implementation). The list is created at start-up time by a bootstrapper and this list is stored in a domain object called "World". This World object is a static object so every other object can reach it when necessary.
Of course this is not the best solution there is, but it works in our project. For more information about dependency injection you can read the following article: http://martinfowler.com/articles/injection.html
Closing words
Recently someone else also started a series about the basics of DDD, although is not very organized in the topic order, he is better organized in the topics itself. You can find his articles here (starting here)

Domain entities and value objects

Three weeks after my last post, it is time to go on with the DDD series.
In this short post I will talk about entities and value objects. These concepts are not new, but are the very important in DDD.

Value Objects

Value Objects are very simple objects which are in the domain for convenience. Nobody cares about the lifetime of these objects because they are very simple to build up again. Some examples of value objects are:

• Color
• Date/time
• Money

The reason why they don't have a lifetime is because we don't care what instance we have. new Euro(10); and new Euro(10); have the same value, we don't care that they don't have the same reference, as long as we can say "We have both 10 euro" it is fine.

Entities

Entities are different. Entities have an identity. new Person("Jan"); and new Person("Jan"); are not the same. They have the same name, yes, but they don't have the same age, or the same length, perhaps they don't even have the same nationality.
This means an Entity is unique and a lifetime should be maintained (even when the application is closed). This means that we should be able to store the entity somewhere and request it again when we need it. And when we request the same entity twice, we need to get the same object.
In my monitoring system Devices and Services are entities. One device can only exist at one place and one Service can only be on one device (even though services can look the same, how we can solve this I will explain in another post :))

Lifetime management

Because entities have a lifetime we need some lifetime management. Although I will explain the following concepts in detail in another topic, I will mention them now to avoid some questions.
The lifetime of an entity is as follow:

• An entity is created, this can be done by using the constructor, or, when it is more difficult and more than one entity has to be created, a Factory can be used.
• An entity is registered to a Repository
• To get a registered entity, we ask the Repository. We can also ask for a list of entities or search through entities.
• When we want to delete an entity we tell the Repository to delete the entity.

In the next post we will talk more about the Factory and the Repository.

Domain Driven Design - The basics

There are a lot of different design techniques in the software development world. At the moment my favorite one is Domain Driven Design (DDD). At my work I was introduced with it two years ago. During those two years I tried to use it to improve my software development and I think I succeeded, although I can improve a lot.

Ok, let me first explain what it is all about.

Eric Evans describes Domain Driven Design in his book Domain-Driven Design: Tackling Complexity in the Heart of Software . He says that the most complex part of software is the business or the domain logic. Software is written to support a business process and the logic that is needed to support this process is called the domain logic. Once this logic is implemented correctly, it is not likely to change very often.

The user interface is more likely to change, especially a web interface like the web site for online banking, therefore it is recommended to separate the domain logic from the user interface and other infrastructure logic (like database or file persistence, logging, etc.).

In DDD the domain logic is designed using a language that is known by the domain experts, and in the implementation (the domain) we will see objects, fields and methods that are using the same language. (Evans calls this the Ubiquitous language) This means the developers and all other people who are working with the domain should know this language.

Ok this can be very abstract, I know, so I will give you an example. For this example I use something everyone is familiar with, a Bank. A bank has clients. These clients have accounts and can do transactions between accounts. The words in bold are important for the bank, without these words/things a bank doesn't exist. Therefore we will add them to out Ubiquitous language. In the domain design we can see the following diagram:

(you can see that I didn't talk about all the details of the classes you see here, but I think they are obvious...)

Now we have the design, we can implement it in any language we want, but it is important that the ubiquitous language is used in the domain itself.

Domain Driven Design is not only about the language. Separating the domain from technical things like user interface is even more important. The complexity of the software is the domain not how we show the domain, or how we implement the persistent. So we should be able to decouple the domain completely from all other things and to test it with some kind of automatic testing framework. (This is needed to get the proof that the implementation of the domain works correctly, but that will be another topic.)

The question is: How do we decouple the domain from the rest of the application? There are a couple of different possibilities here:

• Layered Architecture


• Sunflower Architecture

Layered Architecture

In a Layered Architecture there are layers. A layer can communicate with all the layers bellow itself by using method calls. To communicate with layers on top of itself, a layer should use some kind of event based system. (See image) 
In the diagram you can see that the domain is on top of the infrastructure/platform layer, which means it depends on this layer and we can't easily change from platform. An example: When we use the Win32-API for events (messages) we can't use the domain on other systems than Windows. So we can't easily deploy the domain on a Linux machine and the Testing Framework should understand the same platform/infrastructure. Other technical stuff like the user interface are build on top of the domain layer.

Sunflower Architecture

The sunflower architecture I like the most. It looks like the following image.

The domain is completely decoupled from everything and around the domain we see the other technical stuff like logging, persistence, etc. With this model it is even possible to use a product from an other vendor and couple it via adapters to the domain. (An adapter is just a class that translates message to and from the domain.) This way the domain doesn't have to know anything about the infrastructure layer and can be tested without any problems.

Software Architecture

"Ok, we have those nice architectures, but how to implement that in my projects?" you may think. I would say make a library for every single layer or service. So a library for the domain, a library for the GUI and for the persistence. This way the code is physically decoupled as well, which makes it even easier to test and to replace implementations. Even updating an existing service is easy because the file is not cluttered with other things that has nothing to do with the problem.

This is also in line with the OO-rule "Single responsibility". Which tells that every single object (or module, or service or library) should have one task to do and it should do that well.

Ending words

Besides a ubiquitous language, Evans also describes a lot of design patterns that can be used in domain driven design. I will give you a list with patterns, but I will describe them in some other posts, because I still want to describe where the domain could be placed in the application. First the patterns list:

• Value objects


• Entities


• Services


• Aggregates


• Factories


• Repositories

Some of these I will combine in one post, but others I need to take separately.



I realize that I give a very short introduction of Domain Driven Design. For more information you can go to some of the following websites:

• domaindrivendesign.org The main website of Domain Driven Design.
  


• infoq.com - contains a free book called Domain Driven Design Quicly, which is basically a summary of the book, as well as a lot of other information about programming techniques and technology.


• codebetter.com - collection of blogs that discuss different techniques.
  

The monitor system

In a previous post I described the basic of the project I worked on and how I would implement it now. When starting a project it is good to write down what to expect from the software that is getting developed, this is something that was not really done for the previous version (at least not that I know of). Because I start the project all over again, I will start this new project by writing down that description.

The context

The broadcaster I worked for is using a complex computer network for distributing and broadcasting radio programs. The complete network is spread across the world and monitoring the whole network can hardly be done by hand and will be automated. (Well we did monitor the whole system by hand for some months because we just implemented the system before the software was ready, but that was not funny...)
On the network there are different kind of devices we have to monitor including: computers, modems (for connecting to the Internet) and UPS-es. All the devices on the network should be monitored (when possible) and it would be nice to keep a history of the state of the devices.
The computers are used for several things: first of all programs are played, but before that schedules should be checked as well as the integrity of the files and a lot of other things. All the programs keep a kind of log (of course) but it is useful to hold some of the information on a central place. There are also some OS things that should be monitored like disk-space and memory usage.
When there is something going wrong (all devices on a site are turned off, the play-out at a site is terminated, etc.) alarms should go off and a hot-line should be called, things should be corrected as soon as possible. (Ideally when computers are not accessible due to a network connection error, other programs in the system should be informed as well so they don't try to distribute file to those computers)
From the network side of the system, the network traffic that is generated by the system should be as small as possible, especially the traffic between locations. Although this can be solved during deployment of the system (run the application on each location) we still need to include support for this during design time.

The requirements

Here is a list of the requirements that comes to my mind. This list is not complete, but that is not a problem because I want the system to evolve over time.

• The state of device should be monitored
• The state of applications (play-out, OS, etc.) should be monitored
• Different kind of alarms should be generated
• States of devices and applications should be saved
• It should be possible to configure what and how to check on the network

• It should be easy to add new locations, devices and applications
• Visual monitoring should be easy and always up to date
• Monitoring is critical but less critical then the whole play-out process
• Network overhead should be as low as possible

These requirements can be split in two areas, architecture requirements and functional requirements. I will mainly focus on the functional requirements because these are the easiest to test automatically and will most likely contain business logic.

Project restrictions

This project is started for learning purposes and not to write a complete and fully functional application. I will use this project to learn (and explain) the following things:

• Object Oriented programming
• C# (.NET and Mono)
• Multi platform development (Linux and Windows)
• Domain Driven Design
• Test Driven Development
  
• Perhaps some Service Oriented Architecture (if I see it fit)
• Object Relational Mappers for persistence
• Agile/Iterative project management
• (Design) Patterns
  
• and probably some other techniques that come on my path
  

Well that's all for today, next time I will talk a bit about Domain Driven Development and/or Test Driven Development. (which can go hand in hand :))

From procedural to Object Oriented programming

When working with Delphi a while ago, I was in need to format dates and times. As far as I know there is hardly any build-in support for that in Delphi. A colleague pointed me to a unit (Delphi is working with units, they are similar to header files of C/C++ or the source files of Java and C#) where he had created functions to convert different types of date/time combinations.
Although they worked very well, inside me everything was screaming. I was working with objects all over the project, and now I needed to use procedural functions in my domain. Today I want to try to convert those functions to a real object, which makes it easy to convert from any date/time format to a specific one that is used in the whole company. Why? to show the power of objects ;)

The procedural interface

The unit that is used to convert a specific date and/or time format to another one, for example: 23122008 to 20081223 or 2008-12-23 to a TDateTime object. The code is made to handle conversion errors, so in the time this unit was created (years ago) it would have been very useful. Now (as far as I know) the standard Delphi library has some functionality to perform the conversions. There are around the 100 functions to choose from and some of these functions looks very similar. Similar code can lead us to code duplication and that can lead us to bugs in multiple places. But even these 100 functions don't give you all the possibilities you can have. Every function is working on its own and every result should be stored in memory. To be able to do some calculations or comparisons or multiple conversions we are in need for some other "magic". This magic are objects.

The object oriented interface

Before I describe the interface of the new object, I will describe some requirements for this class.

• It should be possible to parse a given date and or time to a TDateTime object.
• It should be possible to convert a TDateTime object to a specific date and or time format.
• It should be possible to add or remove time to the object.

Basically these are the things that are done in the original unit. Lets see how we can put this in an object: disclaimer, I don't have a Delphi compiler at hand, so I am not sure this is 100% correct.

type DateTime = class
begin

public:

procedure ParseDateTime(value, format : string);
function ToString(format : string) : string;
function Compare(dt : DateTime) : integer;

end;

The method ParseDateTime is used to convert a string to format that is used internally. The method ToString will convert the internal time value to a specific format. Compare will compare the two different values (by using the internal format).

OK, now we have a basic interface how do we implement this and what is our internal value? The internal value should be (in my opinion) in a format that the computer understands the best. In Delphi we can use the TDateTime type (if I remember correct) which is just a alias for a Long type which can be found in most programming languages.
The parsing of the Date and Time values can be done by using functions that are included in Delphi. We can make sure that errors are caught and we can throw an exception (for example IncorrectFormat exception, or something like that). The same we can do for the ToString function. (I won't show a real implementation, because I don't want to show an example with errors.)
To compare two DateTime objects we simply compare the internal values. If I recall correctly Delphi can access private fields of a class instance (an object) from another class instance of the same type, so this shouldn't be a problem. For convenience and to follow standards we return some kind of value depending on the comparison (0 means self equals dt, negative means self is smaller (earlier) than dt and positive means self is greater (later) than dt). There might be a function for this in Delphi as well, but I am not sure.

Time zones

OK, but what about different time zones you might say. How can a datetime from Europe (GMT +1 and GMT +2) be compared with America (GMT -7)? There are a few solutions for this I think:

• We don't mind, so we don't implement
  
• Convert date and time to UTC (GMT 0)
• Use region information

This list is probably not complete, the first item is unacceptable when you have that above question. The second and third (converting to UTC and region info) are going hand in hand.

*Disclaimer* What I write here is pure theoretical, I couldn't test it, but by providing this information, the reader can try it out in his/her preferred programming language.
For converting a date and time format we need to know in which time zone the given time is. There we could use for example the TTimeZoneInformation type form Delphi (_TIME_ZONE_INFORMATION structure in Win32 API). To get the UTC time first convert the datetime-value to a long (as before) and then add the TTimeZoneInformation.Bias value. I am not sure if it is possible to get the TTimeZoneInformation type for other time zones, but it is worth trying.

When you choose to include the timezone info into the DateTime class, you can use this information for comparison as well.

Default formats

Of course there are a couple of default formats you can choose from. The easiest way to do this is to create string constants for them, so they can be included easily.

Conclusion

Although converting programs from procedural to object oriented is very time consuming, it could be done quiet easy when doing it in very small steps. I hope this post gives you a good example of how to approach a typical conversion. When you have questions, please feel free to add a comment :)