Browsing Posts in Software Design

Thanks to everyone who came out for the session to listen to tales of the NHibernate Mafia and how persistence ignorance can improve your domain model. Here is a list of recommended resources:

You can download the code here. NHibernatingNorthwind is adapted from code by Oren Eini. I haven’t included the NHibernate binaries. Download and extract NHibernate 1.2 into ..\tools\NHibernate.

If you have any questions, please don’t hesitate to email me or leave a comment.

The website is now live and accepting registrations. We’re accepting 100 lucky participants to take part in this unique event. Sign up now at If you don’t know what I’m talking about, go back and read this. Hope to see you there!!!

Coming to an Edmonton library near you… One night only…

How does NHibernate enable a persistence ignorant domain model? Why would you want a persistence ignorant domain model? Why does the NHibernate Mafia feel so strongly about persistence ignorant domain models? And who are the NHibernate Mafia anyway? This session will answer all these questions and more.

Date/time: Thursday, August 23, 2007 starting at 5:30pm
Location: Stanley A. Milner library (7 Sir Winston Churchill Square)

You can sign up on the EDMUG website.

After my DNIC video interview, John just wanted to know more about agile development. So we did it again, this time podcast-style. You can check out the audio interview here.

Coming to Austin, TX… October 5-7, 2007… Brought to you by the NHibernate Mafia themselves… 3 days of ALT.NET mayhem… See behaviours twisted, tests tortured, dependencies injected, object-relations mapped, and DSLs like you’ve never seen them before…

More seriously, what exactly is ALT.NET? David Laribee coined the term to describe developers who look outside the “official gospel” for ideas of how to develop software better.

  1. You’re the type of developer who uses what works while keeping an eye out for a better way.
  2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
  3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
  4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. ReSharper.)

Scott Bellware has assembled an all-star organizing committee, including:

The conference will be run in an open space format, which is very agile in nature and execution. Fundamentally OpenSpace is a conference with self-organizing sessions. If you have an idea for a session, you post it on the schedule. If you see a session that interests you, you show up. If that session sparks an idea you’d like to talk about, post your new session on the schedule. Lather, rinse, repeat… This will be my first time participating in an OpenSpace conference, but I’m excited by the concept.

You can expect topics covering:

  • Software design
  • Testing strategies and continuous integration
  • Test-Driven Development (TDD)
  • Behaviour-Driven Development (BDD)
  • Domain-Driven Development (DDD)
  • Domain-specific languages (DSLs)
  • Object-relational mapping (OR/M) using NHibernate
  • Dependency injection with Castle Windsor
  • Web development with MonoRail
  • Agile team practices, such as XP and Scrum
  • Plus anything else that attendees want to discuss

The Important Stuff

Cost: FREE! (except for the cost of airfare and accommodations)
Location: St. Edwards University Professional Education Center, Austin, TX
Date: Friday, October 5th, 2007 @ 5pm to Sunday, October 8th, 2007 @ noon
Attendance: 100 (max)

If you are interested in attending the event or would like to know more, please don’t hesitate to contact me or one of the other organizers.

There are many paths to software enlightenment, to attaining the state of development nirvana knows as ZenBoo. Masters of the art of ZenBoo can invert dependencies at will, value coding to interface* not implementation, favour composition over inheritance,** and respect the open-closed principle.***

On your journey to becoming a ZenBoodist, you will encounter many revelations and wonders. While meditating on test-driven development (TDD), you will gain deeper understanding of the technique. First you will realize the power of an automated test harness and a suite of regression tests that prevent bugs from finding their way into your code base. Next you will realize that your suite of unit tests allows you to confidently refactor your code base. Finally you will discover the power of mocking and realize that TDD is not a testing technique, but an agile design technique. Other wonders abound including better layered architectures, O/R mapping, IoC containers, and more.

How can I achieve a state of ZenBoo, you might ask? Everyone’s path is different, but I offer you a few humble suggestions. You must first understand object-oriented design. Just understanding object-oriented programming isn’t enough. You have to know how to design object-oriented hierarchies through responsibility assignment. Which object/class is responsible for X? By assigning responsibility for X to this object/class, how does that affect my coupling, cohesion, and a myriad of other factors? A good treatise on the subject is Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman.

By understanding responsibility assignment, software patterns suddenly make sense. You have a framework upon which to understand patterns and upon which to build new ones. Everyone should read Head First Design Patterns (Head First) by Eric Freeman and Elizabeth Freeman. This book offers deep insight into the ZenBoodist mind in a playful, approachable way. Although it is written for Java developers, it is equally applicable to and comprehensible by C# developers. It covers the classic “Gang of Four” software patterns, but frames them in within actual problems so that you can see how to apply them. You understand the power of coding to interface not implementation, why we favour composition over inheritance, and how to apply the open-closed principle. If you’re going to read one software book in the next year, this should be it.

Now that you understand the “Gang of Four” patterns and the basic ZenBoodist philosophies, it is time to understand how to design real-world architectures and build real-world applications. For this, we turn to Applying Domain-Driven Design and Patterns: With Examples in C# and .NET by Jimmy Nilsson. He blends together elements of Eric Evans’ Domain-Driven Design and Martin Fowler’s Patterns of Enterprise Application Architecture to take you on a journey of discovery through TDD, mocking, O/R mappers, domain-driven design, and more.

Becoming a ZenBoodist master is a difficult journey, but one well worth it. Once you achieve development nirvana, you will code with elegance, refactor with confidence, and dream in patterns. You will also realize that you are but a humble grasshopper wanting to learn more.

<plug type=”shameless” subject=””>

If you want to get a jumpstart on ZenBoodism, check out Jean-Paul Boodhoo‘s Nothin’ but .NET course. You get 5 days of top-notch training from a ZenBoodist master, a ReSharper 2.0 license, Martin Fowler’s Patterns of Enterprise Application Architecture, and free food. The next course is in Edmonton on February 19-23, 2007. Highly recommended.


<shelf type=”reference”>

The following reference books are useful to have on your shelf, but you probably don’t want to read them cover-to-cover unless you’re crazy. (Yes, I’ve read all of these cover-to-cover and thoroughly enjoyed them.)



* Interface in this context can mean abstract base class or interface. The point is not to depend on a specific type, but on a contract definition.

** Favouring composition over inheritance does not mean abandoning inheritance. True ZenBoodists combine the powers of inheritance with composition to make truly powerful object models. While inheritance is over-used, don’t under-use it either.

*** Open-closed principle: Classes should be open for extension, but closed for modification.


Full Disclosure: The book links above are through the Amazon Affiliates program. If you buy a book through that link, I get more books from Amazon to sate my hunger for knowledge.

Jean-Paul reappears on dnrTV to talk about Model-View-Presenter, which is a cool pattern for abstracting away your UI implementation technology. For example you can re-use the same Model and Presenter code with ASP.NET and WinForms. Additionally the view ends up being really dumb, which means that parsing, validation, and other logic traditionally in your ASPX code-behind or WinFom is now encapsulated in the presenter and can be identical between the two. This episode is well worth the watch.

Jean-Paul Boodhoo on Model-View-Presenter

Also worth watching is Jean-Paul’s earlier double-header on Test-Driven Development (TDD). You want to see how TDD is meant to be done, watch and learn!

Jean-Paul Boodhoo on Test-Driven Development Part 1 of 2

Jean-Paul Boodhoo on Test-Driven Development Part 2 of 2

I’ve had this kicking around in my bookmarks for ages, but I thought I’d share…

Have you ever had to diagram in UML using Visio? It’s a painful process. The UML add-in for Visio has a number of deficiencies:

  • Doesn’t support the latest spec (UML 2.0)
  • Even with the spec it supports, it gets some things wrong (e.g. Completely valid UML will show up with red errors around it.)
  • Using it to really design a software system downright hurts*

* Try the following: Create a sequence diagram. Add some objects and method calls between those objects. Realize that you forgot a step. Marquee and move all the method calls down a notch so that you can insert the forgotten method. Guess what? Visio just forgot all the method names previously entered. You have to manually wire-up the method names again. When actually designing a software system, you are constantly re-ordering methods, removing methods, inserting methods, etc. The team that maintains the Visio UML Add-in should really use their own tool for designing version N+1.

You can’t fault Visio completely. It’s a diagraming tool, not a software engineering tool. So how do you stop Visio from pretending to be a software engineering tool and force it to do what it’s good at (being a diagraming tool)? You grab Pavel Hruby‘s UML 2.0 Stencil for Visio. Thank you, Pavel! You’ve made my time with Visio that much more tolerable.

P.S. Some of you might ask, “Why don’t you use a real UML tool like [insert favourite UML tool here]?” I’m a consultant. As a consultant, it’s often hard to convince a client to buy tools and Visio comes free with many versions of Visual Studio. Typically I’ll need to give my client soft copies of any design artifacts in a file format that they can read. Typically that also means Visio. So like it or hate it, Visio is often the lowest common denominator that all developers on a team can use or have access to.

P.P.S. Some of you might be wondering, given my choice, what my favourite UML tool is? Rational Rose, Borland Together, Sparx Systems’ Enterprise Architect, … I’ve tried a lot of different UML tools over the years and while Borland Together is my favourite UML software package, the best UML designer I’ve ever worked with is definitely a large whiteboard and a digital camera. Honestly, if you can’t design good UML on a whiteboard, the software packages aren’t going to help you much.