Lessons In Domain-Driven Design - Basic Overview

   Submit to Reddit      

Recently I wanted to gain a clear, basic overview of Domain-Driven Design, and I stumbled upon Domain-Driven Design Pattern Summaries document from http://domaindrivendesign.org/resources/what_is_ddd which is an excerpt of the book Domain-Driven Design, Addison-Wesley, by Eric Evans, 2004. The summaries document is licensed under the Creative Commons Deed: Attribution 2.0.

I also watched a presentation by Eric Evans entitled "What I learned about DDD since the book".

After studying the material, I drew a simple diagram to illustrate the Domain Model, in a way that made sense to me.

A Domain Model is a sphere of knowledge.

A Value Object contains a number of attributes that describes an object, but does not provide a mechanism to uniquely identify it.

An Entity is essentially an object that has a specific unique identity.

An Aggregate is a composition of a number of Entities and Value Objects, with one specific Entity being the root/parent/master.

A Repository encapsulates the data access functionality of Aggregates and can emulate access to a collection of objects. The role of the Repository is to provide an object-oriented view of the persistence layer and translate the object-oriented Domain Model to the physical data store.

A Domain Service is used for processes or transformations in the domain that are not the responsibility of an Entity or Value Object.

A Domain Event is some event that occurs that is important to be noted by a Domain Expert. An event happens and the effect is that state is changed.

Lessons In TFS Work Item Customisation - System.State Is Special

   Submit to Reddit      

I was customising some TFS 2008 Work Items, and I wanted to automate it so that the System.State value changes to a new state value when a custom field is changed to a specific value.

Quite simply, you can't do this. The System.State field cannot have a value copied into it, or have other actions done to it.

If you are serious about automating like this, the only workaround is to create a custom program that listens for a particular event or custom action, and then use the rich TFS API and programmatically change the value of System.State.

The same applies to System.Reason.

Lessons In MSBuild - Targets Are Called Only Once

   Submit to Reddit      

By design, targets in a MSBuild process are only called once. This is an important concept to understand, as it is unusual for the typical developer.

I had a situation where I wanted to call the same target from a few places in my MSBuild project - but I wanted to pass in different property values. I didn't want to repeat myself (DRY principle).

If <CallTarget ...> is used then the target is only called once within that process.

I found a sneaky way to work around this by examining the file C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\ Microsoft.TeamFoundation.Build.targets

Instead of using <CallTarget ...>, use <MSBuild ...> which spawns off a new MSBuild process, thus allowing the target to be called each time.

<MSBuild Projects="$(MSBuildProjectFile)" Targets="MyTarget" Properties="MyProperty1=blah;MyProperty2=$(MyVariable)\blah2" />

Lessons in MSBuild - Applying the Single Responsibility Principle

   Submit to Reddit      

As an experienced developer, I promote the use of good practices in object-oriented designs.

I was modifying a number of MSBuild and TFS Build project files for several related environments and I noticed that they both duplicated information and each had more than one responsibility - such as specifying the solution to build and compilation settings such as code analysis, configuring testing, and then perhaps performing some custom operations.

I wondered if I could apply the Single Responsibility Principle to the build project files.

Indeed, you can split your project files into multiple files, and from the main project you can import the other file by using the following syntax.

<Import Project="MyCommonTargets.proj" />