Due to the snow, my flight tonight was cancelled. After much wrangling, the earliest flight I could get back to Denver is tomorrow night. So I will not be be back in time for tomorrow morning’s session. Disappointing, but nothing I can do.

If you are interested in seeing this session come to light at some other time then please let me know and I will try to make it happen via some other venue.

Today is the last day of our 4 day DDD Immersion course here in NYC with Eric Evans, the author of the DDD book, and Kristian Nordal, a DDD practitioner and training from Oslo, Norway. A full listing of all upcoming classes is available at Domain Language.

Due to the weather, the class has been small, but this has been – hands down – the best training experience I’ve had. I’m going to be inserting some of my notes, along with a little commentary here and there.

DDD Immersion Course - Blog Series Summary

Here are links to the entire series:

• Part One – Introduction. What is DDD? Ubiquituous language? a Model?
• Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
• Part Three – Strategic design – Bounded Context and context mapping.
• Part Four – Strategic design (continued) – Core Domain
• Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
• Part Six – Design and agile.
• Part Seven – Final. Course takeaways and other thoughts.

Day 1

The first day was all about introducing the concepts and – like the second day – digging into primarily tactical concerns. We started out by reviewing some basics:

What is Domain-Driven Design?

DDD - a set of driving principles.

1. Focus on the core domain.
   1. Put here the most effort and the best programmers.
   2. Technology and all else is supporting, used as needed.
   3. Put the supporting things in perspective, realize primary focus is somewhere else.
2. Explore models in a creative collaboration between domain practitioners and software practitioners.
3. Speak a Ubiquitous Language with an Explicitly Bounded Context.

It turns out that these principles are really hard to pull off.

DDD - a pattern language.

• A set of interrelated patterns that have helped teams realize the principles.
• A vocabulary and conceptual framework for discussing domain modeling and design.

We then talked through a typical system design, discussing the communication and design challenges we typically encounter when the development team does not take modeling, language and the business domain as seriously as they should.

What is a Model?

A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

• System of abstractions - excludes everything that you are not interested in.

• Selected - such as Mecator projection being useful for deriving compass headings.

• Used - most important

A model serves a particular use.

• Not "as realistic as possible"
• Useful relative to specific domain scenarios

One key insight at this point was Eric’s discussion around specific domain scenarios, and the importance of collecting these early in the process. These domain scenarios use real business data and describe concrete scenarios that are important to the business. They form a good foundation for discussions with the domain experts about how they understand the business to work and what they needexpect the system to do for them.

I saw a lot of parallels here between ATDD/Storytesting and the specific domain scenarios. More on that later though.

What is Ubiqituous Language ?

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Not the one language that describes everything.

Context - the setting in which a word or statement appears that determines its meaning.

Much of this is recap from the book, but it still helped crystallize many of these concepts even clearer for me. I could also see that the course materials reflected Eric’s additional 7 years or so of experience in the trenches applying DDD to newer problems and situations.

Continue to Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)

This week, while attending the DDD Immersion course in NYC, I have been staying at The Jane Hotel in the West Village. It would not be for everyone, but it sure suits me just fine.

As this NY Times article points out:

The original 1908 red brick structure was built as a lodging house for seamen, and its residents included some men rescued from the Titanic. Now, having been renovated by the developers Sean MacPherson and Eric Goode, it is one of New York’s most unusual, and economical, lodgings.

The rooms are tiny but very cosy, and you share a common bathroom. But at under $100/night with free WiFi, flat-screen TV and a quite street in the West Village, it was just right for me. Here is what the room looks like. Notice the giant mirror on one wall.

The doors to the stairs and corridors have portholes(!). And the corridor reminds me of what you would typically find on a yacht or cruiseliner, not a hotel.

As the NY Times article continues:

…a guest gets the same rooms that the seamen got, a bunk on one side, some storage on the other, and barely enough space to turn around. However, they are fitted out like yacht cabins, with polished wood, as well as flat-screen TVs, WiFi and iPod docking stations. The bath is where it always was: down the hall.

The West Village is very picturesque in places, with beautiful streets that ovoke nostalgic images of horses and carriages and late 19th century life (minus the plastic bag and Jaguar of course). So if you are looking for somewhere a little different that is only a 5 minute walk from the 14th and 8th st subway, in a historic part of town, I can highly recommend it.

This Saturday is the Rocky Mountain Tech Trifecta. Over 500 [Updated: Julie Yack just informed me we have 630 registered as of this AM!] people are registered for this free (yes, free!) event. Why aren’t you?

If you are attending, then drag yourself out of bed a little earlier and come to my Design/Software Architecture birds of a feather (BOF) session at 7:30am (yes, 7:30am!!!) in room 1535. 

To sweeten the deal, I will have also have some awesome prizes to give away (books, a JetBrains license, and an Infragistics license)!!!

No excuses here, I will be fresh as a daisy after my late night flight back from NYC tomorrow night. I expect everyone else to be raring to go. Or, at least, to have had enough coffee to get their heart rate up.

If you are interested in agile design and testing, or on an agile project and struggling with how to go about it, then this BOF session is for you. The main focus will be on the different types of testing, how they integrate with our design efforts, and how we get better at making them “play nicely together.” Here is the session information:

Testing the Architecture: Getting design and testing to play nicely together

If we cannot test our systems, then we cannot validate that they function as they should: testability is crucial for the systems we create. We now have a huge variety of options in terms of testing tools and frameworks - ranging from unit test frameworks such as MSTest, NUnit, xUnit and MBUnit, to Automated Test-Driven Development (ATDD) frameworks such as Cucumber and FitNesse. But good design and writing tests are often the first thing to go when the pressure is on. In this session we will discuss the different types of software testing that can be done, the relationship between testing and design, and what types of testing approaches might be appropriate for your situation. Come prepared to share your testing experiences and challenges, and to gain insights on how to build quality in every day.

I will be sharing some of what I have learnt, but this  is primarily a hands-on, interactive session with lots of peer-discussion about your questions and struggles around doing architecture, design and testing in an incremental and iterative process. I hope to see you there!

Like Joe Hewitt , I am optimistic about the potential for the iPad. And with my interest in iPhone development in .NET, I am looking forward to playing around with iPad-optimized applications later this year.

I just got an invitation to obtain a free iPad by becoming a fan of the Apple iPad Research Team on Facebook. Given that the iPad is not publicly available yet and the relentless manner in which scams are propogated, you might want to be wary of these types of offers.

Better yet, for some good laughs read Harry McCracken’s article: Oh No, the “Free iPad” Offers Are Here! (which is where the image on the right was sourced).

One of the things we noticed, and were quick to correct, in our Keeping Architectures Relevant presentation was some confusion around the way we were using the word “domain.” As we explained, when we use the word “domain” in Domain-Driven Design (DDD) we are referring to the business domain. By this we mean what the business knows and does to serve its customers. This use of “domain” is not unique to DDD, by the way.

The developers are trying to mine the nuggets of business knowledge that “domain experts” or “subject matter experts” (SME’s) have about the business domain. This knowledge is based on the experts’ years of experience “doing the work” of the business.

Sometimes the Product Owner (i.e., person responsible for the success of the software product under development), to use the Scrum terminology, plays the role of domain expert, but in many situations it could just as easily be the sales and marketing staff, or technical people within the business who have a long-term and intimate understanding of how the business works.

Domain experts are the people who understand the in’s and out’s of the business, and to whom the developers typically go when they need to find out what the software should do and how it fits in to what the business needs.

We ran into some problems in the presentation because we also referred to the problem domain and solution domain, right after we had carefully defined domain in the narrower sense of “business domain.” So we took a couple of minutes in the presentation to define our terminology and referred to them as areas of focus, expertise and responsibility for the problem and solution space.

We decided that we also need to revise the final draft of our Architecture Journal article early next week and refer to ‘domain’ exclusively in the more narrow sense above, and instead refer to the “problem space” and “solution space” in the article and future presentations to avoid any confusion.

See the table below for an initial attempt to break down the focus, expertise and areas of responsibility of the domain experts and developers in the problem and solution spaces:

These roles are somewhat fluid though, and will vary from team to team and context to context. Is this how it works in your environment?

I was privileged to co-present on February 4th with IASA Austin chapter president, Brandon Satrom, at the first ever IASA Austin ITARC conference.  Our presentation was titled “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture” and was intended to be a helpful introduction to some key ideas in each of these areas, geared particularly towards an audience of software and enterprise architects.

We had a great time, and recieved some very helpful feedback after the session. In particular, we realized that we took more time than expected to explain Ubiquitous Language. There also seemed to be more interest in StoryTesting using Cucumber than I was expecting. We found that we needed to clarify our terminology around how we use the word ‘domain’ (I will blog about this soon).

The presentation was an adaptation of many of the ideas from our forthcoming Architecture Journal article (March 2010 edition). Once the article becomes available online then I’ll post the link.

In the meantime, if you attended our session then please post your comments here. I would love to hear what you thought.

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):

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.

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.