Home >

Domain-Driven Design Immersion Course – Part #1

26. February 2010

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)

Pingbacks and trackbacks (4)+

Comments are closed