Domain Driven Design

Thinking Inside the Box and Premature Optimization

Matthew Podwysocki — Tue, 26 Feb 2008 18:57:16 GMT

At the last DC ALT.NET meeting, there was a good discussion regarding premature optimization. Anything that involves this brings me to a rather famous quote by a great computer scientist, Donald Knuth which states:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Don't Think Five Steps Ahead

The context of the conversation revolved around how when you learn a new language, you have a tendency to think inside the box and try not to prematurely optimize the code, instead, just meet the original intent of what you were trying to do as quickly and efficiently as possible and make it conform to the specification. For example, one person there was a .NET guy who knew nothing of Java until put on a project recently where it was exclusively used. This forced him to think more clearly about the problem and not just throw design patterns, caching solutions and so on. When we are familiar with a language and all of its nuances, it sometimes gets the better of us, and we start throwing frameworks in there that have done things for us in the past just because they seemed appropriate then. It rang very true for me as well when I did my first Ruby on Rails application and I saw that I didn't need to bring in X framework or Y framework and my solution did just fine without it. In fact, I thought it was a stronger piece because I didn't clutter it with frameworks and instead solved the direct domain problem at hand first.

It kind of reminds me of a conversation I once had with a developer which went like this:

Me: Why did you use x for this piece?
Him: Because it's always worked for me in the past.
Me: What problem does it solve? Did you have that problem this time around?
Him: Well, no, I was just thinking five steps ahead

So, basically what we can infer from this conversation is that the pain point just hadn't been hit yet. Instead, reflexively, we have a tendency to throw these things in there because at one point, for one particular project, we felt that pain. That's not to say that optimization is a bad thing, but once we start doing it, we need concrete measures for what the optimization is trying to fix and how well it does it. Another part to consider is how easy is it to read.

ADD with DDD

Some of the guidance for this can be traced back to Domain Driven Design. With this, you pay more attention to the model, the ubiquitous language and so on, and the frameworks in turn will come into play. Instead, many people put their frameworks first and try to get the domain model to fit around it. They are distracted by shiny things with their ADD to put the domain model first and then the frameworks. I know I've been guilty of it in the past and it's been a learning adventure when I was earlier in my career.

I'll be back next with a real technology post on IoC, Unity and all that, so stay tuned. Until next time...

Aspect Oriented Programming with .NET with Windsor

Matthew Podwysocki — Thu, 24 Jan 2008 00:40:15 GMT

Update: Fixed some code issue and added a bit more discussion

With our DC ALT.NET group, we've discussed IoC quite often as part of the discussion. Some are pretty new to the concepts of using Dependency Injection with these IoC containers. Instead, you'd find people with overloaded constructors all over the place and mocking out the dependencies in the unit tests and so on.

Anyhow, I have two favorite IoC containers, being Jeremy Miller's StructureMap and Castle Windsor. If you unfamiliar how to use Castle Windsor, there is a nice set of tutorials here. I'd have to say StructureMap is the lightest weight of all of them and I like the fluent interfaces for configuration, but when I need other things as well, like AOP, I switch to Castle Windsor. Which brings us to today's post.

Why AOP?

With object oriented programming, we try to break down things into small, distinct parts with as little overlap as possible through Separation of Concerns (SoC). However, some of these concerns defy any sort of encapsulation by having cross-cutting concerns. Some of these include logging, transactions, security among other things.

So, what options do we have for AOP in the .NET world? Well, we have three that are mainstream and supported at this point:

Castle Windsor
Spring.NET
PostSharp

Today I'm going to briefly talk about Windsor Interceptors. It's a powerful concept for being able to intercept calls while using Castle Windsor and quite easy to use. Let's go through a quick sample.

Castle Windsor has an interface that you must implement in order to write an interceptor called IInterceptor that looks like this:

public interface IInterceptor
{
    void Intercept(IInvocation invocation);
}

So, let's create one for a simple logging application:

public class MeddlingInterceptor : IInterceptor
{
     public void Intercept(IInvocation invocation)
     {
          Logger.Write("Entering method " + invocation.Method.Name + " with user " + Thread.CurrentPrincipal.Identity.Name);

         // Maybe do some user validation
         invocation.Proceed();
         // Do some stuff afterwards if need be as well
     }
}

And now let's configure it to use with our class we have already defined called EmployeeRepository.

public class EmployeeRepository : IEmployeeRepository
{
     public void Save(Employee employee)
     {
          // Calls database to save employee
     }
}

And inside our config file is this lovely mess:

<component id=”meddlinginterceptor”
service=”Podwysocki.Interceptors.MeddlingInterceptor,
    Podwysocki.Interceptors”
type=”Podwysocki.Interceptors.MeddlingInterceptor,
    Podwysocki.Interceptors” />
<component id=”employeerepository”
service=”Podwysocki.Interceptors.IEmployeeRepository,
    Podwysocki.Interceptorsr”
type=”Podwysocki.Interceptors.IEmployeeRepository,
    Podwysocki.Interceptors”>
<interceptors>
    <interceptor>${meddlinginterceptor}</interceptor>
</interceptors>
</component>

As you can see, I didn't have to change anything in my EmployeeRepository class at all in order for this to work. It works rather seemlessly. With the IInvocation interface, I can get the method name, the target, arguments and so on. But, I also have the ability to reset any of those arguments as well.

Imagine I want to wrap transactions so that it doesn't appear in my code and just happens behind the scenes. Well, I can do that too through a given interceptor as well.

public class TransactionInterceptor : IInterceptor
{
     public void Intercept(IInvocation invocation)
     {
          using(TransactionScope scope = new TransactionScope())
          {
                // Maybe do some user validation
                invocation.Proceed();
          }
     }
}

Now, do I recommend that? Well, that's another story because O/RMs are probably a better way to go with handling that, but still this can be done.

AOP in Domain Driven Design???

In a previous post, I covered the assertion that proper Domain Driven Design cannot be accomplished without AOP. The assertion is that the domain model needs to stay as clean as possible, so that all other cross cutting concerns such as logging, transactions, security and whatnot do not belong in your model. Instead, AOP needs to be implemented. This of course has been hot topic on the Domain Driven Design mailing list.

Randy Stafford had a great response on this thread and I thank him for it. He seems to indicate that it's not really necessary for most things and I'd have to agree. To read his responses, they are here and here.

Conclusion

A lot of the Domain Driven Design stuff has me rereading Eric Evans book again looking for nuggets I missed the first time around, so it's definitely time to get back reading. I've got way too many books on my pile!

New Book - .NET Domain-Driven Design with C#

Matthew Podwysocki — Mon, 14 Jan 2008 14:19:21 GMT

No, I haven't written a book, well, not just yet. Anyhow, so far in the Domain Driven Design world, we have a few references of how to do Domain Driven Design. These books are an invaluable resource for doing DDD, but at the end of the day, they don't have as many end-to-end solutions. The current books/bibles on DDD are:

Some of these books are great, but left me wanting at a complete end to end solution. Also, The discussion of Value Objects versus Entities was not very well covered in the Jimmy Nilsson book, which left me a bit frustrated. So, there is definitely more material needed on the subject.

Tim McCarthy has started a book called .NET Domain-Driven Design with C# : Problem - Design - Solution which is due out in April of this year. This definitely looks promising as an end to end scenario of how to do DDD in the context of .NET solutions. Tim has also been gracious enough to host the code example from his book on CodePlex, which can be found here. Slides are also available from his presentations on "Building an Offline Smart Client using Domain Driven Design Principles".

Here's the description of the book from the site:

This first technical title of its kind, this is a revolutionary book for the object oriented developer. It takes the reader through the intense process of building a real-world application using Domain-Driven Design principles implemented in C# 3.0 (.NET Framework 3.5). The reader is introduced to a business domain of a real-world Construction Administration application for an architecture firm. The application is ma critical, legacy MS Access application that has outgrown MS Access and is ready to become a full-fledged enterprise application. In each chapter, the relevant part of the domain is modeled out via diagrams and code. The application is built using C#, Windows Presentation Foundation, and other Microsoft technologies and best practices. The main focus of the book is on designing and implementing the domain model and all of the supporting patterns and framework that are built in support of the domain model. The emphasis is on these theories in action through the working application, not on the tools used. The main goal is to show how to take a set of requirements and user scenarios and apply Domain-Driven Design principles to the requirements in order to create a domain model that satisfies both the user requirements and the system requirements. Various patterns are introduced along the way in order to aid with certain activities such as adapting the domain model to the user interface, synchronizing data between the client and the server, validation, mapping, etc. Although this particular application is a WPF application, most of the design patterns introduced and applied in the book can be used on other types of applications, such as web applications, web services, etc.

With the Problem-Design-Solution promise and approach, the chapters are broken down into their own modules where the intent is to take the reader through the process from beginning to end while building a complete project with each chapter module. Each chapter establishes the problem, what the reader wants to do, and why it is important, and then what factors and restrictions need to be taken into account. Next the chapter covers how the programmer will solve the problem with an adequate solution that will provide only the best results. Finally, the developer produces code and other materials to better realize the design and solution to the problem. This part of the chapter is where the reader gets hands-on practice at creating code that builds applications.

Like I said above, it should be an interesting book when it comes out. I'll do a review once it does as I'm hoping for the best!

Domain Driven Design Cannot be Adequately Implemented without DI and AOP

Matthew Podwysocki — Mon, 14 Jan 2008 04:23:07 GMT

There have been a lot of things lately that have been grabbing my attention with regards to Domain Driven Design and definitely some things I've missed. It's all about my continuous learning about this subject that's near and dear to my heart. Back in 2006, Ramnivas Laddad gave a presentation entitled Domain Driven Design with AOP and DI. In this talk, he asserts that you cannot implement Domain Driven Design without the help of Aspect Oriented Programming and Dependency Injection.

He states several problems with DDD as designed by many people. He contends that our POCOs became only mere data collections when they should have not only the data, but the behaviors as well. This in turn makes the domain model weak and most of the reliance came upon the service

So, how do we get around those issues? He contends that in order to have a rich domain object, you need collaboration with other objects. This means that you need a web of objects that mirrors the domain model. You also need DI at the domain level, and that using configuration nor factories may suffice for this, hence the DI needed. Also, crosscutting domain concerns are not mapped well using objects alone. AOP is needed to address these concerns. This will cover the tracing, auditing, transaction management and so on.

An indiciation you've already run into that is that your objects have a dependency on transaction management, and that all your business layer logic is exclusively in the service layer. So, the session really covers that fine grained DI with AOP can help your domain objects gain back some of their smartness and that AOP can keep your domain clean as well. This session is well worth a listen whether you agree or disagree.

I agree with the assertion that AOP can keep the domain model clean and it's a high priority on my list to do so. For those looking at AOP, there are a few .NET frameworks worth looking at:

I can honestly say I've only looked at PostSharp and Spring.NET for this, so I can't really speak for the others I've found PostSharp quite easy to use with compile and runtime weaving. I wish it were more native to the .NET framework as a whole, and I think it may be coming if Microsoft Research releases Phoenix. A download is available on this site for you to give it a go.

Also, Ramnivas Laddad posted a session on Leveraging Annotation with AOP that is also well worth a watch.

Until next time, Develop, mentor and inspire!

Object Mother Pattern versus Test Data Builder Pattern

Matthew Podwysocki — Tue, 08 Jan 2008 06:11:11 GMT

When creating my unit tests, I've been a big believer in the Object Mother pattern for creating state for my immutable value objects. Basically, I need to put the objects in a valid state in the constructor. Doing such is usually a pain, however. Before the ObjectMother pattern, you had code similar to this to create an object in valid state, such as a medical claim.   Remember that we need hundreds of these to capture the variations in our model for our tests.

Claim claim = new Claim(
     new DateTime(2008, 1, 1),
     new Provider("Robert", "Jones",
          new Address("1800 28th St, NW", "Washington", "DC")),
     new Recipient("James", "Smith",
          new Address("1210 14th St, SE", "Washington", "DC")),
     new ClaimLineCollection(
          new ClaimLine("00308-1")));

Object Mother

As you can see, quite a mouthful for just one object in the correct state. Instead, we could just mask it behind the Object Mother approach. If you're unaware what the Object Mother pattern is, below is the basic idea.

Object Mother starts with the factory pattern, by delivering prefabricated test-ready objects via a simple method call. It moves beyond the realm of the factory by

facilitating the customization of created objects,
providing methods to update the objects during the tests, and
if necessary, deleting the object from the database at the completion of the test.

So, let's come up with an example of this for our problem up above:

Claim claim = ClaimObjectMother.CreateFootSurgeryClaim();

And we would encapsulate the code from above to pass in the appropriate values to that. But, soon, you'll find that your Object Mother is becoming a God-class and becoming cluttered with every variation that we can for unit testing the claims in our domain. This can add up to a lot.

Test Data Builder

So, what are the alternate approaches? What about a Test Data Builder? And what is it anyways? Well, it's just an extension of the Builder Pattern to create our test objects for testing our domain. I got the inspiration after reading a post from Carel Lotz a while back. Although he insists it's more of a DSL instead of the Builder Pattern. And as you can note, this approach was combined with the Object Mother instead of using this as a complete alternate.

Let's take a look at an example of this:

public class ClaimBuilder
{
     private DateTime claimDate;
     private Provider provider = ProviderBuilder.StartRecording().Build();
     private Recipient recipient = RecipientBuilder.StartRecording().Build();
     private ClaimLineCollection claimLines = ClaimLinesBuilder.StartRecording.Build();

     public static ClaimBuilder StartRecording()
     {
          return new ClaimBuilder();
     }

     public ClaimBuilder WithClaimDate(DateTime claimDate)
     {
          this.claimDate = claimDate;
          return this;
     }

     public ClaimBuilder WithProvider(Provider provider)
     {
          this.provider = provider;
          return this;
     }

     public ClaimBuilder WithRecipient(Recipient recipient)
     {
          this.recipient = recipient;
          return this;
     }

     public ClaimBuilder WithClaimLines(ClaimLineCollection claimLines)
     {
          this.claimLines = claimLines;
          return this;
     }

     public Claim Build()
     {
          return new Claim(claimDate, provider, recipient, claimLines);
     }
}

As you can see, the implementation of a Builder pattern is rather easy. But, how easy is it to implement our test cases?

Claim claim = ClaimBuilder.StartRecording()
     .WithClaimDate(new DateTime(2008, 1, 1))
     .WithProvider(ProviderBuilder.StartRecording()
          .WithName("Robert", "Jones")
          .WithAddress(AddressBuilder.StartRecording()
               .WithStreetAddress("1800 28th St, NW")
               .WithCity("Washington")
               .WithState("DC")
               .Build())
           .Build())
      .Build())
     .WithRecipient(RecipientBuilder.StartRecording()
          .WithName(James", "Smith")
          .WithAddress(AddressBuilder.StartRecording()
               .WithStreetAddress("1210 14th St, SE",)
               .WithCity("Washington")
               .WithState("DC")
               .Build())
           .Build())
      .Build())
     .WithClaimLines(ClaimLinesBuilder.StartRecording()
          .WithClaim("00308-1")
          .Build())
     .Build());

Conclusion

You can shorten things up a bit with these builders to not be as verbose as I am right here. I could not care about certain parts of my domain when building these objects and choose to fill in only things I need to in order to my tests to pass. Overall, I think this helps the readability of the test data that I am using. What's really powerful is having builders interact with other builders to create complete test cases for our domain. I think I'm leaning towards this for my Entity objects as well. I'll continue looking at this and trying to tweak it a bit.

.NET 3.5, Design by contract and Spec# Wrapup

Matthew Podwysocki — Tue, 08 Jan 2008 04:07:47 GMT

Update: Adding Visual Studio Integration discussion
Update: Stay tuned for additional posts in this series as things permit

Well, this is my last post in the series to wrap things up. This will be updated as things come to mind, as they always do in a series like this. There may have been unclear things that I will attempt to explain a little further, plus clarify and explore new things.

Let's get caught up from the series:
Part 1: Spec# introduction
Part 2: Method Contracts (Preconditions/Postconditions)
Part 3: Invariants
Part 4: Object Ownership/Assertions & Assumptions
Part 5: Frame Conditions/Inheritance/Boogie
Part 6: Implementing a non-null string collection in Spec#

Now let's go over some topics I may have missed earlier:

Constructor behavior
Pure methods
Immutables
Visual Studio Integration with C#

Constructor Behavior

When using non-null types in your Spec# code, you need to be careful about when your object is initialized. In .NET, the order of the calling of constructors is non-deterministic, meaning that the base constructor may be called before the super class's. In Spec#, if you have a non-null field declared, you must initialize it, so therefore you need to control the order in which the constructors are called. Fortunately, Spec# gives you that capability, and allows you to call the base constructor at any time during the constructor of your superclass through the use of the base keyword. Below is an example of that:

public class NonNullStringCollection
{
     private List<string!>! strings;

     public NonNullStringCollection()
     {
          strings = new List<string!>();
          Debug.WriteLine("Before base constructor");
          base(); // Must call this after initializing all non-null fields
          Debug.WriteLine("After base constructor");
     }
}

So, unlike C# and others, we have the ability to control the flow of our constructors. By this, it is pretty powerful as we need to do this. How does it look like in IL where I'll highlight where it verifies the call of the constructor
.method public hidebysig specialname rtspecialname instance void .ctor() cil managed
{
    .maxstack 8
    L_0000: ldarg.0
    L_0001: newobj instance void [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)>::.ctor()
    L_0006: stfld class [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)> modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType) SpecSharpSample.NonNullStringCollection::data
    L_000b: ldstr "Before base constructor"
    L_0010: call void [System]System.Diagnostics.Debug::WriteLine(string)
    L_0015: ldarg.0
    L_0016: call instance void [mscorlib]System.Object::.ctor()
    L_001b: ldstr "After base constructor"
    L_0020: call void [System]System.Diagnostics.Debug::WriteLine(string)
    L_0025: ret
}

If you look at the C# version through Reflector, you'll notice no difference whatsoever:

public NonNullStringCollection()
{
    this.data = new List<string modopt(NonNullType)>();
    Debug.WriteLine("Before base constructor");
    Debug.WriteLine("After base constructor");
}

Pure Methods

If you want to call a method in a specification, then the method you call must be pure, which means it has no effect on the state of objects allocated at the time the method is called. In order for a method to be considered pure, it must be marked with the PureAttribute, ConfinedAttribute or StateIndependentAttribute in the Microsoft.Contracts namespace. In order to do this, it's rather easy:

[Pure]
public void DoesNotModifyState() { ... }

All three of the above attributes mark the method as pure. It also declares what the method may read, so let's look at that below:

PureAttribute - this method may read anything
ConfinedAttribute - this method can only read the state of the receiver object and its representation objects
StateIndependentAttribtue - this method does not read any mutable part of the heap.

Over time, it's the plan of the team to migrate to just a simple PureAttribute and I'm not sure as of this writing if that is done. The default read permission is set to the ConfinedAttribute, so until the name change is complete, it's best to use that one.

Immutables

Some objects in the .NET framework will remain "peer consistent" forever once their constructor has finished. Recall back to the ownership and invariants discussion for that definition. If a type is marked with the ImmutableAttribute, then the fields and such are not allowed to be modified once it has left the constructor. To think about these, think of such objects as DateTime, Guid and other value objects, by the fact that you cannot modify them once they have been created.

[Immutable]
public classCoordinate
{
     public Coordinate()
     {
          this.longitude = LongitudeMinValue;
          this.latitude = LatitudeMaxValue;
          base();
     }

     public Coordinate(double latitude, double longitude)
     {
          this.longitude = longitude;
          this.latitude = latitude;
          base();
     }

     public Coordinate Add(double latitude, double longitude)
     {
          return new Coordinate(this.latitude + latitude, longitude + this.longitude);
     }
}

As you can note, I'm not changing this after I've finished constructing them. I don't mean Value Objects in the DDD sense of the word, although it could possibly apply here as well when it comes to Entities versus Value Objects. Anyhow, by default, these value objects are peer consistent. The String class is immutable, so your program can always invoke methods on strings because since it is always immutable, it will always be peer consistent.

In order to make your own objects immutable, you need to make sure it has no peers. The static verifier, Boogie, checks to make sure no expose operations (expose keyword) is applied in the class as well. Fields using the PeerAttribute are not allowed in immutable classes. Also, there is no need to own an immutable object, since the reason for owning an object is to keep it peer consistent, and by default, immutable objects are peer consistent.

There are three restrictions you must note when using an immutable object.

A Constructor of an immutable class must end by calling its base constructor.
Can only be declared if the base class is also immutable
A class or interface that derives from an immutable type must also be declared immutable.

Let's wrap this up with pure methods. An immutable class can only invoke pure methods on its fields due to the state of the object not being allowed to change.

Visual Studio Integration with C#

When you install Spec# for Visual Studio 2005, by default it will install the project templates for Spec#, which includes the standard stuff plus a few extras including:

Class Library
Windows Application
Console Application
Sample Projects
- ArrayList
- Bag
- Subclass with Invariant
- Use Mscorlib contracts

Now when you choose to use the Spec# templates, you give up a lot of the C# features that you have come to love. This also hurts especially when using a tool such as Resharper to make me a productive developer. You also give up auto-indentation as well, so if you want it, you do it yourself!

But, on the positive side of things, you get the feedback from the static verifier to give you the red and green squigglies that display not only syntax errors, but also theorem prover errors coming from Boogie. How cool is that? Also, as I mentioned in a previous post, you get Intellisense to display the contracts of other classes as you highlight them.

But, say for instance, you still want the rich environment of C# to do Spec#. Well, you can do that, too. In my first post in the series, I alluded to the fact that you could do Spec# in C# but to comment it out so that C# doesn't detect it, but Spec# will.

To make a non-liar out of me, create a new C# project, and right click on the project and go to properties and you should see this following screen:

This screen allows you to do compile time checks on your code as you build it. First, the project will build in C#, and then hand it off to Spec# for your post-compilation. It's probably a similar process to what the BCL team did when they incorporated the Microsoft.Contracts namespace into System.Core.dll.

To use these Spec# contracts in your C# code, it's as simple as commenting out your contracts with this:
/*^ Do Spec# thing here; ^*/

Below is a quick example of this:

public class NonNullStringCollection
{
    private List<string/*^!^*/>/*^!^*/ strings;

    public NonNullStringCollection()
    {
        strings = new List<string/*^!^*/>();
        /*^base();^*/
    }

    public void Add(string/*^!^*/ value)
        /*^requires value != null;^*/
        /*^ensures Count == old(Count) + 1;^*/
    {
        strings.Add(value);
    }

    public int Count
    {
        get
            /*^ensures result >= 0; ^*/
        {
            return strings.Count;
        }
    }
}

Let's look at the constructor to make sure our base constructor gets called last:

    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed
    {
        .maxstack 8
        L_0000: ldarg.0
        L_0001: newobj instance void [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)>::.ctor()
        L_0006: stfld class [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)> modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType) NonNullTypes.NonNullStringCollection::strings
        L_000b: ldarg.0
        L_000c: call instance void [mscorlib]System.Object::.ctor()
        L_0011: ret
    }

If you try compiling without marking base(); in the constructor, you might notice it right at the top of the method call. Also, let's take a look at the resulting C# created for the Add Method:

[Requires("::!=(optional([System.Compiler.Runtime]Microsoft.Contracts.NonNullType,string),string){$1,null}", Filename=@"E:\Work\NonNullTypes\NonNullStringCollection.cs", StartLine=0x12, StartColumn=0x19, EndLine=0x12, EndColumn=0x26, SourceText="value != null"), Ensures(@"::==(i32,i32){this@NonNullTypes.NonNullStringCollection::get_Count{},::+(i32,i32){\old(this@NonNullTypes.NonNullStringCollection::get_Count{}),1}}", Filename=@"E:\Work\NonNullTypes\NonNullStringCollection.cs", StartLine=0x13, StartColumn=0x18, EndLine=0x13, EndColumn=0x2f, SourceText="Count == old(Count) + 1")]
public void Add(string modopt(NonNullType) value)
{
    int old(Count);
    try
    {
        if (value == null)
        {
            throw new ArgumentNullException("value");
        }
        if (value == null)
        {
            throw new RequiresException("Precondition 'value != null' violated from method 'NonNullTypes.NonNullStringCollection.Add(optional(Microsoft.Contracts.NonNullType) System.String)'");
        }
        old(Count) = this.Count;
    }
    catch (ContractMarkerException)
    {
        throw;
    }
    this.strings.Add(value);
    try
    {
        if (this.Count != (old(Count) + 1))
        {
            throw new EnsuresException("Postcondition 'Count == old(Count) + 1' violated from method 'NonNullTypes.NonNullStringCollection.Add(optional(Microsoft.Contracts.NonNullType) System.String)'");
        }
    }
    catch (ContractMarkerException)
    {
        throw;
    }
}
Conclusion

So, as you can note, there are plenty more opportunities to dig deeper and I hope you all get the bug to do so. If I missed anything, let me know! I would love to use such a thing in production, but it's not designed for such right now. Also, the licensing states that it's for academic uses only at this point. But, who knows what the future holds for this. Design, mentor and inspire!

DC ALT.NET Meeting 1/15/2008

Matthew Podwysocki — Thu, 03 Jan 2008 04:31:32 GMT

We are announcing our second meeting of DC ALT.NET on January 15th at 7PM.

The meeting this month will bring ALT.NET to CMAP. Are you a developer who always keeps an eye out for a better way? Do you look outside the mainstream to adopt the best practices of any development community, including Open Source, Agile, Java, and Ruby communities? Are you always looking for more elegant, more simple, more maintainable solutions? If so, then you might be an ALT.NET practitioner!

This group follows the Open Space Technology model. In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups.

This model follows the four basic principles:

Whoever comes are the right people
Whatever happens is the only thing that could have
Whenever it starts is the right time
When it's over, it's over

Topics for discussion can include the following as well as others:

Model View Controller Pattern (ASP.NET MVC/MonoRail)
Inversion of Control (IoC) containers and Dependency Injection (Spring.NET/Castle Windsor/StructureMap)
O/RM Tools (NHibernate/ActiveRecord/Entity Framework/LINQ)
Test Driven Development
Domain Driven Design
Behavior Driven Development
Design by Contract and Spec#
Enterprise Design Patterns in .NET

Time and Location:
Tuesday, January 15, 2008 7:00 PM

SM Consulting
1306 Concourse Drive
Suite 200
Linthicum, MD 21090

Come, participate, and make your voice heard! Come meet passionate developers like yourself in the active discussion

Making Myself Better for 2008

Matthew Podwysocki — Wed, 02 Jan 2008 03:25:59 GMT

Last year was a very good year for me, but I'm always looking for ways to learn more and better myself for the next year. After all, it is hard to top 2007, the year in which I buy a house, get married and have a great honeymoon in Italy. So, somehow I need to top myself yet again!

Anyhow, these are the things I'm looking to do this year to make me a better designer, developer, etc:

General
- Read a new book a month
- Run a marathon (Well, only running 5 miles a day right now)
General Development
- Give more user group presentations (DC ALT.NET/CMAP/etc)
- Master Ruby and Boo
- Continue deep dive with MVC frameworks
- Contribute more to open source
ALT.NET
- Organize an ALT.NET Code Camp Track
- Stay active in the DC ALT.NET community and the ALT.NET community as a whole
Blogging
- More posts with coding examples
- More downloadable samples
- Be more responsive to questions (sorry about that)
- Explore BDD and DDD more

Rather ambitious, I know, but it's always great to look back earlier on the year to see what changed over the year and what really happened.

Starting Junior Programmers on the Right Agile Track Guidance

Matthew Podwysocki — Wed, 02 Jan 2008 00:53:05 GMT

Part of my job is not only to design and implement solutions for my customers, but also to make my customer's developers stronger as well. During these customer engagements, there are many times when junior developers are involved. My job is to help those on the team to be stronger and then in turn help become leaders.

Where to start?

Well, I could start with a stack of point technology books (ASP.NET, SharePoint, BizTalk, etc) that become obsolete right during their printing, so that's not where I start. You find that many times, the books were written during the beta phase of the product and sure enough, things change, rapidly... But, I will mention a few that earn my admiration that form a basis for a good development background.

So, first things first, surveys are always in order to find out the comfort level with such things as:

Agile Software Development
Scrum
Domain Driven Design
Test Driven Development
Object Oriented Design
Enterprise Design Patterns
Secure Development Lifecycle
Point Technologies (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)

So, as you can see, it's quite a list of things to cover. But, no matter, we can come up with a list of things to know and teach and how to do it.

Topics to Know

When it comes to making stronger Agile Object Oriented Designers/Programmers, it's important that they know a few topics inside and out. They can be found easily on the net and some books that I will feature later on. Some of these include:

Separation of Concerns
Breaking a program into distinct features that overlap in functionality as little as possible. A concern is any interest or focus in a program. Concerns are synonymous with features or behaviors.
Liskov Substitution Principle
Subtypes must be substitutable for their base types
Law of Demeter
A given object should assume as little as possible about the structure or properties of anything else, including its subcomponents.
Single Responsibility Principle
Every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.
Open/Close Principle
Software entities should be open for extension, but closed for modification. The entity can allows its behavior to be modified without modifying the source code.
Interface Segregation Principle
Modules that encapsulate high level policy should not depend upon modules that implement details. Rather, both kinds of modules should depend upon abstractions. Abstract classes should not depend upon concrete classes and concrete classes should depend upon abstract classes. Clients should not be forced to depend on methods that they do not use.
Dependency Inversion Principle
Virtual member functions of derived classes must expect no more than the corresponding member functions of the base class; and should promise no less. It also means that virtual member functions that are present in base classes must also be present in the derived classes; and they must do useful work.

Stocking the Library

Knowing these fundamentals go a long way to making a stronger object oriented programmer. Ok, so reading just an article or two doesn't always make things sink in. Some books may be in order to help as well: Let's walk through some fundamental books for solid developers. Note that these do not include any point technologies, and instead focuses on gaining strong fundamental skills. It's not enough to pick up an ASP.NET book, and boom, you're a solid developer. So, let's go through some of them:

But what about technical books diving into point technologies, well, there are some of them that come highly recommended:

C#/.NET Framework
- CLR via C#, Second Edition (Jeffrey Richter)
- Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)

This by no means is an exhaustive list, but a way to get started. By no means should they read all these books at once and should be tailored for those who need work in those related areas. These books will get the junior developer starting to think abstractly in a more agile mindset. But, how do you reinforce these behaviors in the development environment. It's not enough to read a few articles, a few books and call it a day.

Going to the next level

In order for those developers to get to that next level, paired programming is the key. This can reinforce what they have learned in a nuturing environment and even those who are more senior programmers can still learn a thing or two. One great way to get this kick started is to do Test Driven Development between programmers. Have the first programmer write a unit test and have it fail. Hand the keyboard off to the next programmer and have them make the unit test succeed. Then work on refactoring and move onto the next. Simple things like these go a long way.

Mentoring is also important. Have a mentor assigned to check how the junior developer is doing with learning these new concepts. Follow-up from the mentors is important as you track their progress. Make time to answer questions and challenge them.

What about Agile?

Many organizations in the software development world don't work in an Agile mindset, so what are some of the ways to get there? An Agile Coach is a great way to start an organization on the right step. No, they aren't the Agile Police, nor should they be. The Agile Coach brings quite a few things to an organization. These can include:

Ramping an organization up on agile processes and ways of thinking
Experience with the Agile Process
An effective agent of change
Environment assessment
Being a certified Scrum Master

Holding brown bag sessions is quite important in reinforcing learned ideas and learning new things. Of course you must make it worth people's while to attend. These can also get the junior developers more excited and involved and people can take turns creating these sessions and presenting.

Conclusion

I hope this post gets you in the mindset of changing organizations for the better, getting junior developers to become stronger ones and creating a more dynamic atmosphere. This of course is only the beginning on a lifetime or learning and being challenged. Develop, mentor and inspire!

Domain Driven Design Videos & Podcasts & Links

Matthew Podwysocki — Fri, 28 Dec 2007 17:06:00 GMT

For those like me interested in Domain Driven Design (DDD), I have worked to compile a list of videos and podcasts to learn more about it. For those unfamiliar with DDD, the idea was founded by Eric Evans in his 2004 book, Domain-Driven Design: Tackling Complexity in the Heart of Software. Jimmy Nilsson followed this with a very nice book using C# called Applying Domain-Driven Design and Patterns: With Examples in C# and .NET that is well worth reading.

DDD was founded on two principles:

For most software projects, the primary focus should be on the domain and domain logic (as opposed to being the particular technology used to implement the system)
Complex domain designs should be based on a model.

Also, DDD should use a common language for describing system requirements that works for both business analysts and software developers alike. DDD also includes the design patterns such as the following:

Entities - An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity.
Value Objects - An object that has no conceptual identity. These objects describe a characteristic of a thing.
Repository - methods for retrieving domain objects should delegate to a specialized repository object such that alternative implementations may be easily interchanged.
Factory - methods for creating domain objects should delegate to a specialized factory object such that alternative implementations may be easily interchanged.
Service - when an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services.

Ok, now that the introduction is out of the way, onto the links and videos:

Eric Evans on Domain Driven Design
Ever since Eric Evans wrote the book Domain-Driven Design in 2004 he has been a significant voice advancing domain modeling and design concepts. In this interview with Floyd Marinescu he talks about some of the recent refinements in Domain-Driven Design and how people are advancing the field today.
Eric Evans on .NET Rocks
Eric Evans offers his insights on good software development using Domain Driven Design techniques.
Eric Evans on DDD: Strategic Design
This talk introduces two broad principles for strategic design. 'Context mapping' addresses the fact that different groups model differently. 'Core domain' distills a shared vision of the system's "core domain" and provides a systematic guide to when "good enough" is good enough versus when to push for excellence.
Eric Evans on DDD: Putting the Model to Work
This talk will outline some of the foundations of domain-driven design:How models are chosen and evaluated;How multiple models coexist;How the patterns help avoid the common pitfalls, such as overly interconnected models;How developers and domain experts together in a DDD team engage in deeper exploration of their problem domain and make that understanding tangible as a practical software design.
Eric Evans - Three Practical Steps Toward Domain-Driven Design (torrent)
Eric Evans has a talk from JavaZone 2005 available via torrent with three practical steps toward DDD.
Jimmy Nilsson on Domain Driven Design
Jimmy Nilsson, author of 'Applying Domain-Driven Design', talks about the value proposition of Domain Driven Design and how DDD integrates with Agile. Jimmy also answers questions on OOD vs. DDD and the symbiotic relationship of domain specific relationships with DDD.
Software Engineering Radio - Episode 8 - Eric Evans
In this interview, Eric talks about the essential building blocks of domain-driven design as well as about a set of best practices on how to address complex projects. In a third part, he elaborates on the relationship of domain-driven design and MDSD/MDA.
.NET Rocks! - Jimmy Nilsson on Domain Driven Design
In this episode, Jimmy Nilsson gets into Domain Driven Design, and how it relates to Test Driven Development, extreme programming, and the future of programming techniques in general.
Aspects of Domain Model Management (Not a video, but interesting)
Using a domain model is rarely as easy as just creating the actual domain model classes and then using them. Soon enough one discovers that sizable amounts of infrastructure code will also be required in support of the domain model.
Domain Driven Design Yahoo Group
Most of your DDD related questions can be answered here.

So, as you can see, there is a lot to read and listen to. I know for my long rides to and from work that they are quite good listens. Develop, mentor and inspire!