David Perfors

xUnit.net vs MSpec?

2010-04-02T11:24:00.000+02:00

For my personal projects I use MSpec as a testing framwork. MSpec had it's advantages and disadvantages. Here is an example of a test I wrote.

37 public class When_setting_the_state_of_a_host

38 {

39 private static HostCheckResultCommand command;

40 private static HostCheckResultCommandHandler commandHandler;

41 private static IRepository _repository;

42 private static Host _host;

44 Establish context = () =>

45 {

46 _host = new Host("asterix");

47 _repository = MockRepository.GenerateMock<IRepository>();

48 _repository.Expect(x => x.GetById<Host>(""))

49 .IgnoreArguments()

50 .Return(_host);

51 _repository.Expect(x => x.Add<Host>(null)).IgnoreArguments();

52 command = new HostCheckResultCommand("asterix", HostState.Up);

53 commandHandler = new HostCheckResultCommandHandler(_repository);

54 };

56 Because of = () => commandHandler.Execute(command);

57 It should_have_a_HostStateChanged_event = () => ((IEventProvider)_host).GetChanges().First().ShouldBeOfType<HostStateChanged>();

58 It the_event_should_have_HostState_Up = () => ((IEventProvider)_host).GetChanges().First<HostStateChanged>().NewState.ShouldEqual(HostState.Up);

59 }

MSpec has a lot of advantages:

Once you are used to lambda expresions, it is relative easy to read.
Since every test is in it's own class, tests can't conflict with each other.
Every test statement (It) is named and run even when another test statement failes.

Disadvantages:

Everything in the class should be static, since the use of anonymous functions.
Can be difficult to get started.

At work I started using xUnit.net as testing framework.

1 public class A_Person : XPODatabaseTestFixture

2 {

3 [Fact]

4 public void can_be_created()

5 {

6 Person person = ObjectSpace.CreateObject<Person>();

7 Assert.NotNull(person);

8 }

9 }

Well we don't compare the tests, because they are completly different, but we can compare the frameworks.
The main advantages xUnit.Net has are:

Every test is performed isolated, for every test method a new instance of the object is created.
The test runner is very fast, tests are run in different threads, multiple at a time.
Can use the constructor for common setup and IDisposable for teardown. (Setup and teardown contain logic that is run before and after each test. other frameworks use the [Setup] and [Teardown] attributes)

The only disadvantage I found in both (and other) test framework is that there is no VisualStudio testsrunner provided. You either need to use the extenal test runner they provide, or a tool like Testdriven.Net, Resharper or DevExpress Coderush.

Although I like MSpec very much, I am going to dump it for xUnit.net. With xUnit.net I don't have to think about making my members static.

CQRS the simple way.

2010-02-19T13:54:00.000+01:00

CQRS stands for Command Query Responsibility Segregation and is a pattern that splits an application into two parts: Commands and Queries.
Queries are used to get data from a datasource (like a database) and commands are used to do something with the data.
The simplest form of CQRS is the following:

public interface BlogQueryService
{
    IEnumerable<Blog> GetAllBlogPosts();
    Blog GetBlogPost(int blogid);
    IEnumerable<Comment> GetAllCommentsForPost(int blogid);
}

public interface BlogCommandService
{
    void NewBlogPost(string title, string text);
    void EditBlogPost(Blog editedBlog);
    void AddComment(int blogid, string comment);
}

The BlogCommandService just updates the datasource with the given data (and does validation if needed) the query service just return simple data.
Of course this is not scalable and a lot of advantages that Udi Dahan and Greg Young describe are not here, but it is a first step to decouple a lot of applications.

Make development easier and faster with unit testing

2010-02-15T13:45:00.000+01:00

As software developers we always come across bugs, some bugs are not very difficult to fix and other bugs are more difficult. Sometimes it is even hard to find the place in code where the bug is coming from and sometimes when we fix a bug we introduce several other without knowing it.
The solution for this problem are unit tests.

Another problem we have is that the user wants to know that the software (s)he is using is reliable. We as software developers should be able to tell the user that the software we are writing is reliable. And we should be able to tell that we have implemented features the way the user wants it and not the way we think they want it or should use it. Basically the user is king.
The way to get some reliability is unit testing.

So what are unit tests?
A unit test is code that is testing the software we have been writing or are going to write. You can test software on multiple levels.
First we can test functions/methods directly like this:

public int Add(int x, int y)
{
    return x + y;
}

[Test]
public void TestAdd()
{
   int result = Add(2, 3);
   Assert.AreEqual(5, result);
}

Second you can test bigger parts of the system:

   1:  [Test]

   2:  public void When_playing_files_that_donot_exist_give_error()

   3:  {

   4:      ProgramPlayer player = new ProgramPlayer();

   5:      try

   6:      {

   7:         player.Play("filethatdoesnotexist.mp3");

   8:         Assert.Fail("Exception was not thrown");

   9:      }

  10:      catch(FileNotFoundException ex)

  11:      {

  12:          Assert.IsNotNull(ex);

  13:      }

  14:  }

And you can test complete usecases and programs.

For most people it seems like wast of time to write unit tests. When I first started with unit tests it was like I wasted time (although at that time I was at university), but after some time and a lot of improvements I realized that unit testing does help. Last year I had to write code for some really difficult calculation. A colleague made the calculations on paper so that I could validate it.
So I wrote some tests for all those calculations and I started to work out a solution.
I soon found out that is was easy to split up the solution in multiple parts, so I wrote unit tests for each part of the solution as well and soon I had a working implementation.
At that moment I didn't even have a user interface to test it in. I found out that working with unit testing is much faster than without. You can test specific parts of the program very fast without the need of starting the application and navigate to the place where you are using the feature you are testing.

Refactor spagethi Form code to something usefull

2010-01-07T10:08:00.001+01:00

There are a lot of applications that are very difficult to maintain. The original writers would not always agree about that statement, but others will see their code as an unmanageable mess.
I will not blame the original writers of those applications. A lot of them started with software development as their hobby or out of interest. During time they learned some "best practises" by reading tutorials about how to write desktop applications using forms (like in Visual Basic or Delphi). These tutorials tell you that in the event handlers you put the code that should be run when somebody presses a button or when an item is selected. There are even components like timers that could let you do stuff at specific times / intervals.
For tutorials this is OK and I did it as well, but I realised that it is plain stupid to do so. The problem is that you get large chunks of code within event handlers and forms. At some point it will be difficult to know where some piece of code can be found. Is it on FormA, FormB or (even worse) on both?

In the rest of this post I want to describe some small steps to re-factor to easier to maintain and understand code. As an example I use a simple application to manage data from media files. There is a form that add/edit music, it has a save button and a close button.

Get code out of event handlers.

The first step is to get event handlers as small as possible. Put all the code that is currently in the event handler into a method and call that method in the event handler. An example:
In the form for adding and editing music information we have a lot of code in the OnSaveClicked event handler. There is code to see whether we are adding or editing the music, there is code to fill the data set (or the sql query, or whatever we are using for persistence) and there is some validation code. That would be at least 15 to 30 rows of code. (depending on how much information we can fill in). By moving all this code to a separate method we can easily call this same method from the OnClosed event handler to let the user save the changes when closing the form.

Split code that is interacting with the controls from other code.

In the method to save the music information we are still asking the information from every input control. So let say we have a textbox to fill in the year of when the music is written, we would call txtYear.Text to get the information. We will probably do this at least two times (one for the validation, because this is a required field and two for saving the value). When we want to change to control to a DateTime control, we have change the code for validation and the code for saving the value which could lead to unexpected behaviour (a.k.a. bugs).
A better way would be to have a method that accepts parameters (one for every field that should be saved). You will then get the following code:

public void OnSavedEvent(object sender, EventArg e)
{
    SaveMusic();
}

private void SaveMusic()
{
    string name = txtName.Text;
    // int year = Int32.ParseToInt(txtYear.Text); // we used a textbox but now we have a special control called YearPicker which gives back an integer.
    int year = yearPicker.Year;
    string composer = txtComposer.Text;

    SaveMusic(name, year, composer);
}

private void SaveMusic(string name, int year, string composer)
{
    // do a lot of stuff with name, year and composer
}

This way we can easily change a control without worrying about whether something goes wrong with saving the data.

Separate concerns.

To be honest, I don't like to much knowledge within a form. A form is there to display data and to handle input and a little but for orchestrate the application flow (more on this in a later post).
Doing stuff with data (and getting the data) could better be done in a separate class. So we can create a class called MusicDataService, which has the SaveMusic(string name, int year, string composer) method. It will also get some methods to load the data.

public struct Music
{
    public string Name;
    public int Year;
    public string Composer;
}

public class MusicDataService
{
    public void SaveMusic(Music music) {/* lot of stuff to be done... */ }
    public Music GetMusicWithName(string name) {/* lot of stuff to be done... */ }
}

public class MusicAddView()
{
    private MusicDataService _service = new MusicDataService();
   public void OnSavedEvent(object sender, EventArg e)
   {
        SaveMusic();
   }

   private void SaveMusic()
   {
        Music music = new Music();
       music.name = txtName.Text;
        music.year = yearPicker.Year;
       music.composer = txtComposer.Text;

       _service.SaveMusic(music);
   }
}

Now that we have the knowledge of saving music separated from it's form, we can use the same code at multiple places if we want.

Smaller methods.

As I said the SaveMusic method in the MusicDataService contains a lot of logic. It validates the input and it makes sure that it gets persisted. Since validation on it's own can contain a lot of code, it is recommended to put this in a separate method as well. This gives us an other advantage. We can now validate the Music structure multiple times even when we don't want to save. When editing the object we can directly validate the input and gave the user feedback.
The real implementations of validating and saving data I will not show, since this is very specific for each applications and there are just to much ways of doing it (and frameworks that could be used). This said it is probably a good idea to make that code pluggable, so we can swap the implementation if we want to. (how to do this could be another post.. you can also use google)

Conclusion.

In this post I tried to show that using some easy steps it is not to difficult to make your program easier to maintain, easier to test and easier to understand for new software developers. And this all leads to a more solid application.

Excellent post about CQRS by Udi Dahan

2009-12-10T14:03:00.000+01:00

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

2009-12-09T10:52:00.000+01:00

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

2009-11-20T15:59:00.000+01:00

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:

Inject a Bus
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.

2009-11-18T13:48:00.000+01:00

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?

2009-11-05T20:01:00.000+01:00

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

2009-10-27T20:30:00.000+01:00

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

2009-10-21T09:09:00.000+02:00

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

2009-10-14T20:17:00.000+02:00

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

2009-10-14T19:36:00.000+02:00

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

2009-10-13T22:18:00.000+02:00

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

2009-10-12T22:33:00.000+02:00

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!

2009-09-15T14:18:00.003+02:00

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

2009-09-02T16:28:00.002+02:00

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

2009-04-08T21:21:00.002+02:00

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

2009-03-25T23:44:00.002+01:00

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

2009-02-16T12:42:00.002+01:00

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

2009-02-13T12:05:00.002+01:00

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

2009-01-21T10:51:00.004+01:00

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

2009-01-07T10:42:00.002+01:00

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

2009-01-05T15:18:00.002+01:00

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 :)

Project description

2008-12-21T17:46:00.002+01:00

One of my first big projects I worked on was a system to detect problems on a play-out network. During this project I learned a lot about software design (I forced myself to use Domain Driven Design) and object oriented programming. But after some time, when the system was already in use, I thought that the design could be better and easier. In this post I want to describe the system, its current design and how I see the new design.
I will use the new design in other posts to describe different aspects of software development and techniques.

The system

When working on this project I worked for a radio broadcaster that uses different transmission site to broadcast their radio programs. On these transmission sites the organisation has a computer network, which are used to automatically play the radio programs. Those little networks are connected to each other and to some distribution sites. The distribution sites take care of sending the radio programs to the right station a few days prior to the scheduled broadcast.

Because the organization doesn't have employers on the transmission sites, there was a need for a system that monitors the state of the network and whether the radio programs are playing or not.

The current design

In the current design I made a separation between "clients" and "servers". The clients were the applications on the transmission site and the servers were the applications on the distribution sites. Both client and server show the state of the network, the client from the transmission site, the server from all transmission sites. The client does the monitoring of the network and devices and send status/change messages via TCP/IP to the servers.

Internally I made a little domain model. I have a Site, a SiteRepository interface to search for a specific site or device. Each site has several CommonDevices. A device has a Name, an Address and an Online status.
There are some devices that need more information, for example the Computer. The computer is derived from the CommonDevice and has a PlayQueue and a PlayStatus.

Checking the status of devices is done in two different ways. Active, the application is running one or more threads that actively check the state of a particular device. Passive, the application get status messages via a TCP message/command server.

The problem of this whole design is that it is not really expendable, for every new device that should be checked, a new class should be created. So I think of a completely different design.

The new design

There is a very easy few for the whole system. Basically there are devices and services. Devices can have multiple services and a service contains the information that should be shown (for example the play queue which lists radio programs that are queue for play-out). This makes the model a lot easier. I now have a Device which has a status (Online, offline or unreachable) and its Name and Address. Devices are connected to each other, so every device need to know its Parent as well. (or its children, or both, I am not sure about that yet.) This way it is possible to tell that a Device is unreachable, because another device between the unreachable device and the device that is checking the status is offline. I will write more about this structure in another post.
So now we have Devices, but we still lack functionality, what about the play-out status and the play-queue? This can be solved by adding Services to the devices. A Service has a Name, a Status and Data. The Status indicates whether the service is running correctly or not. The data contains information about a specific service, for example the queue items in the play-queue.

By using this model it is possible to add a lot of other devices and services. The only problem I still see is how does the application determine the status of the Device or Service? A possibility is to add a Command class that contains the information about how to check the status. The question is whether this Command class belongs in the domain or not.

Disclaimer

It is possible that someone is reading this and thinks "This sounds familiar...". That could be possible. The same concept (except for the object oriented way of working) is already realized by
Nagios. Nagios is a network monitoring system created by Nagios Enterprises. It is released as Open Source Software under the GNU General Public License, but is only running on a Linux host. Since the organization I worked for is using Windows on it's computers, it was not an option to use it.
My project is started as learning project for object oriented programming and other development techniques. Since Nagios is not object oriented (but written in C) I think it will not hurt anybody when I use the concepts of Nagios. This project is started for personal use, and I might decide to release it under an open source license.

Introducing myself

2008-12-18T11:06:00.004+01:00

Hello, my name is David Perfors. since summer 2007 I am a graduated programmer.

For one year I have worked for a Christian radio broadcaster as a programmer. We were using Delphi and I developed a system to monitor the state of the play-out system. The play-out system is a network of computers that play radio programs on a specific time. Beside computers there were other devices as well that needed to be monitored.

Currently I am working for a software firm using C# .NET and Java. As a personal training project I wanted to rewrite the monitoring system using different techniques I am learning now.

Some techniques are:

Domain Driven Design (I was already using this, but I did not make use of all the possibilities)

Test Driven Development

NHibernate

.NET / Mono

Well, the last two are not really techniques but frameworks, but I need to learn how to use them ;)

One of the reasons I start blogging is to write down my findings and experiences. But I will probably not blog only about programming/development, but also about other things I like to do. I am a great fan of Linux and Unix and I like to investigate applications and projects that run on it (like Asterix, mutt and Nagios). Photography is a hobby that I started this year, and I just want to share some of the pictures I took.