Virtual Genius Blog

Complex Business Domains

When software is developed for a business with where the domain is complex, new systems often fail to account for this complexity in the core parts of the business.  This leads to lost opportunities to mine the richness of the domain and encode it in the software itself, resulting in systems that are brittle and difficult to change along with the business as it grows and adapts to new market opportunities.

Domain-Driven Design (DDD) is a philosophy and approach to developing object-oriented systems for businesses with highly complex domains. The central idea is to develop a rich domain model and express it as clearly and rigorously as possible in the software itself. The central ideas for DDD were developed by Eric Evans and published in the “big blue book”: Domain-Driven Design: Tackling Complexity in the Heart of Software in 2004.

DDD is a fundamentally different approach from the more typical forms-over-data application approach, often using the ActiveRecord pattern made so popular with Ruby on Rails, that businesses tend to adopt when developing standard business applications. DDD advocates for domain modeling as the central focus of development, and thus considerable effort to be expended in encoding the richness of domain behavior into the heart of the software itself. I will expand on this in future posts.

Recommended DDD Books

For those wanting an introductory text, go to InfoQ and download Domain-Driven Design Quickly (104 pgs, pdf). The text is a free download, and the print version is available for purchase for $30.

I have used this book very successfully as my standard introductory text on DDD for new developers. The big blue book can be a lot to bite off for someone, and DDD Quickly dramatically eases the spread of ideas throughout the team.

I also have used it as a great “bridge-text” for business analysts (BA’s), testers and other non-developers on a project where DDD principles and practices are being applied. Business analysts will really appreciate the increase in communication that developing a ubiquitous language for expressing system behavior.

Developers working in .NET that have read Eric’s book and are looking to go deeper can find a helpful companion in Jimmy Nilsson as he walks through many practical examples in Applying Domain-Driven Design and Patterns: With Examples in C# and .NET.

This book was a tremendous help to me as I initially struggled to understand DDD distinctives and apply them to the problems I was trying to solve. It also has good examples of applying Test-Driven Design and UI design patterns in the context of DDD.

Other Resources

Another good source of information is the Domain-Driven Design community website. This has a good list of resources, including links to presentations and webcasts, as well as examples and links to local communities.

For an ever-growing list of DDD resources see my Delicious bookmarks on DDD .

Finally, I did an introductory presentation on DDD at IASA Denver last year (thanks again to Dave Laribee for giving me permission to adapt some of his ideas for this presentation):

ddd

I’ll be attending the Lean Software & Systems Confence in Atlanta this April (21-23), presenting this session:

Measure for Measure: Lean Principles for Effective Metrics and Motivation

This presentation explores the nature of motivation and the place of metrics and measurement in software development, and how lean software development principles and practices shed light on motivation and metrics and how they can be used to support deep organizational improvement. We will examine the nature of motivation in terms of the four intrinsic rewards that drive positive engagement, and also how certain approaches to measuring and managing performance lead to organizational dysfunction. We will also show how the application of lean principles such as building quality into the product, respect for people and optimizing the whole enable more effective approaches to motivation and metrics in software development.

I have been interested in metrics and measurement for a while now, and concerned about how a naive understanding and application of various types of instrumentation in agile projects actually works against agile values. I said as much when I participated in the Agile Denver “Metrics in Agile” panel discussion last August. However, when applied carefully and thoughtfully, I think metrics and measurement have a great deal of value. These are some of the thoughts I will be expanding on in my session. I hope to present this session publicly at least once in Denver before April, so stay tuned.

I highly recommend this conference for anyone interested in implementing Lean software development principles in their organization. The official Twitter tag is #lssc10. I hope to see you there.

agile, lean, conferences

In a new forbes.com article, “Why Lean and Agile Go Together,” Dan Woods asserts that agile succeeding at large scale requires the application Lean manufacturing principles.

It is important to note that he is talking about principles, not practices. As Mary and Tom Poppendieck point out in Implementing Lean Software Development, manufacturing is fundamentally different from the product development that occurs in software development. The difficulty is often in determining how best to map Lean principles to software development, and there are differences of opinion among the Lean software development community on how best to do this.

The article states that:

In essence, as a practical matter, good ideas from Agile are being absorbed into a new approach to software development that is more Lean than anything else. Someone else can name this phenomenon, but Lean and Agile are merging.

I would add that they must merge, and that the marriage of these two will produce something new, exciting and innovative as we move into this new decade. In my agile coaching I do my best to emphasize the need for applying Lean principles, especially as they apply to portfolio and product management. One of the major Lean concepts that helps with this is that of the value stream or, as the Poppendiecks say, the activities that occur between driving a software product idea from concept to cash.

Dan Woods has an excellent description of how the concept of value streams fits into the larger picture of Lean manufactoring.

In a Lean manufacturing system, the work is broken into a set of value streams triggered by demand signals. The output of one value stream leads to others. Value streams may be executed sequentially or in parallel as needed. Eventually, everything is combined into the product. The suppliers for materials needed are alerted through a system of just-in-time replenishment of parts and components called Kanban.

I recommend the article, particularly for those at the executive level looking for a high-level introduction to the basic ideas of agile and Lean software development. The article mentions Ryan Martens from Rally, and he makes a few comments of his own here.

agile, lean

UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. It also is the default setting for some text editors such as Notepad++ on Windows and Textmate on the Mac. For Mac users, according to the manual, TextMate is heavily biased toward UTF-8.

I typically do all my text editing in Notepad++, and discovered only today at my client that the default of UTF-8 was causing a couple of strange things to happen when Cuke4nuke processed the feature files.

Using UTF-8 for Cuke4Nuke feature files will likely manifest itself as funky characters displayed before Feature in first line of the output. It's always the same 3 bizarre characters, so the reason is likely the header of the UTF-8 file. This is a minor issue though, and should not affect the function of the tests. You can see it clearly here in the Google example that comes with Cuke4Nuke:

The other, more serious, issue is that when I placed a tag such as @wip (i.e., indicating work in progress) on the first line of the feature file (before the Feature line) then using the --tags option would not work correctly for that tag. For example, with the following entry in our Nant build file I should have seen the feature we were working (tagged with @wip) being ignored in the CruiseControl.NET build, but that was not the case.

<exec program="${cuke4nuke}" workingdir="${ui.source.dir}Test">
<arg value="${ui.source.dir}Test\bin\Release\Test.dll"/>
<arg value="--tags ~@wip"/>

Cuke4Nuke would still try to execute all the scenarios in the feature file with the @wip tag on the feature, even though we had not yet completed any of the scenarios.

Richard Lawrence suggested I change the encoding of the files to ANSI (in Notepad++ just select Format->Encode in ANSI), and that did the trick. So it would seem that Cuke4Nuke is not currently handling UTF-8 encoded feature files correctly, and ANSI-encoded feature files are the way to go until this issue is resolved.

NOTE: Here is an update from Aslak Hellesøy:

Try to save as UTF-8 *without* BOM. I think that's possible with Notepad++. It's a good thing that TextMate defaults to UTF-8. Every time I try to use my name Aslak Hellesøy in an application - and it's rendered as garbage it's always because the developers have used a different encoding.

atdd, cuke4nuke, .net

I have decided to move my blog from it's current location to my own hosted instance of BlogEngine.NET. I have been using Live Spaces for my blog for a number of years, but am frustrated with the lack of support for many of the features I need. It is too time consuming to migrate the content, so I guess the old blog will languish in its current location in perpetuity. I looked at Subtext and DasBlog, both noble blogging engines, but decided that BlogEngine.NET was the best solution for my needs.

So far I am liking BlogEngine.NET as a blogging platform, and look forward to a smoother workflow with getting content onto my blog from now on.