I’m charging forward on the Shared Resource Schedule Service. There are a lot of things I’m getting into place before I start writing code. Don’t try to tell me that I’m not being agile either, you always need to design a little to write good code. The key to being agile is designing only as much as you need, and being prepared to change your mind later.

The Name

The first order of business was to choose a name. It helps to know the name before you create a project. I’m also hoping to put the source in a public repository right away so that I can talk about the coding process while I build it.

Themis comes from Greek mythology. According toWikipedia, she “is the embodiment of divine order, law, and custom.” That seems somewhat applicable to the subject at hand. I know thatGreek mythology isn’t too creative, but we can always change the name later if anyone has a better idea.

Application Structure

This system should be very simple. It’ll have a windows service to check for invitation emails, a web page to view schedules and configure the service, and a database to hold all the information so that both apps can access it. For simplicity, I want to put most of the code into a single assembly.I want to the web UI and the service runner to be a thin veneer over the main assembly.

Application Design

Although this is just a home project I do want it to be good quality, even if my name weren’t going to be pasted into every source file with the license. To achieve this, I will be using unit tests in as many areas as I can add them; not only to catch my mistakes but to help others understand and maintain the system after I’m gone. To make unit testing easier, I want to use anIoC / DIcoding style.

I’m going to use Entity Framework to keep the application code ignorant about the database. I don’t want to be tied to a particular database system, though I suspect most installations would use a sqlce database. I could use any ORM, but I’ve been wanting to try EF.

Processing Mail

Now that enough of the design (and some of the non-coding elements) have been straightened out, I can start to really focus on the first part of the project:Processing email.

I want to build the email handling logic as a group of small components,each responsible for a single aspect of the process. Aside from some shared types to hold email or request data, and the controller that knows how to orchestrate them, none of the components will know anything about each other. Even then the controller won’t know which types contain the actual implementation thanks to the IoC container.

By building each part in isolation I get a few good advantages. First, I’m able to test each component completely and separately from the rest of the system. Second, it becomes possible to replace any part of the chain with nothing more than a configuration change, which will be especially handy if anyone wants to fork the code. Third, I can reuse the individual components for other parts of the system, and they are likely to require less refactoring before they can be reused.

This is the new coding style: you build a system with complimentary building blocks loosely hooked together. You end up with a lot of classes, but you avoid the pain of complex inheritance trees.

The Next Step

Now that I’ve figured out my approach, I see that my first step is too big for an afternoon. Instead, I’m going to tackle it in three smaller steps:

  1. Receive any email and send a simple response back.
  2. Receive event invitations by email and send a human-readable response listing the details of the invitation.
  3. Receive event invitations by email and send an acceptance email. (The original requirement.)

All I have left is to make a good cup of tea, turn up the music,and bang some keys.