Site Sections
Posts
58
Comments
103
Trackbacks
10
Wednesday, October 17, 2007
Screencast: Test-Driven Domain Model

I put together a TDD screencast this week after having the same conversation more than once.  It boils down to the topic of whether people can actually write their unit tests before writing their code.  With this screencast, I wanted to illustrate that it's not only possible, but that it's also highly productive (once you get the tooling right).

This is not an introduction to TDD, nor an introduction to domain modeling, DDD, or any other high level concept.

If you want more information on the techniques used in this screencast, I will direct you to the following resources:

  • The Domain Model Pattern
    • Very Brief Writeup on Martin Fowler's Blinki (I recommend you add his feed to your RSS reader)
    • A longer description can be found in his book, Patterns of Enterprise Application Architecture, along with complementary and alternative architecture patterns.  PoEAA is the authoritative book on a multitude of architecture patterns as found in the wild.
    • A highly recommended methodology on building domain model applications can be found in Eric Evans book, Domain Driven Design (also lovingly refered to as DDD).  I highly recommend it as well.
  • Test Driven Development
  • Object-Oriented Programming
    • This is the foundation for everything else.  If you can't name at least three principles of object-orientation (and I'm not talking about "polymorphism", "encapsultation", etc), then I recommend brushing up on them.
    • Robert Martin does a good job laying them out in Agile Principles, Patterns, and Practices in C#
    • For advanced learning, people tend to go with one of the Head First books or Craig Larman's book.  I've mostly seen people practicing Responsibility-Driven Design (within the context of TDD/DDD) in the wild.

You can download both the screencast (Windows Media - 50 MB) and sourcecode here.

The tools used in this screencast include ReSharper, MbUnit, and Test Driven.NET.

I'll try and get another screencast up soon which shows building domain services, the service layer, and data access (ie.. putting the domain model to work).

Please feel free to email me if you have questions/flames/comments on this in the mean time.  My email address is evan@thisdomain.com.

kick it on DotNetKicks.com
posted @ Wednesday, October 17, 2007 6:47 PM | Feedback (13)
Pragmatic Dogma

While reading Greg Young's post on the topic of the ubiquitous language and behavior driven development, something stuck out at me.  I am quoting Greg who is quoting Eric Evans:

Alas, I too have had stakeholders such as what Scott describes. In fact thinking back many of them were in the sorts of domains that I would not recommend DDD and recently Eric Evans has also had had this discussion.

I became more and more aware that one of the basic mistakes that model enthusiasts made from the start was the idea that we should just model everything, that the whole system should modeled and object oriented and so on. what I have started to realize is that that dilutes the effort to the point where we don't really ever get the bang for the modeling buck and that in fact most systems are probably 90% CRUD (create, read, update, delete) and that there are simpler solutions to that problem.

I'll leave you with this thought:

Pragmatism without context is really dogma in disguise.  We learned this long ago when defining software patterns.  There is a higher level of understanding which exists of nearly everything.  You will know you've reached that level of understanding after you have fully understood the item, and then understood it's limitations.  Until you can grasp the limitations, be wary of the dogma effect.

That being said, I do think the domain model pattern is grossly underused in the enterprise application space.

posted @ Wednesday, October 17, 2007 6:17 PM | Feedback (2)
Archives
Blogroll