Recap of SysArt’s Domain-Driven Design seminar

The seminar was organized by SysArt. The topic is Domain-Driven Design (Wikipedia): an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.

The quest speaker was Jimmy Nilsson (@JimmyNilsson on Twitter), CEO of factor10 and the author of Applying Domain-Driven Design and Patterns.

I’ll use my LESS2010 recap method for this post: notes with regular type and my own comments and questions with italics. As these notes are mostly for myself I’ll mostly write about things that interest me the most.

Jimmy Nilsson: From Requirements to Code

How I see the world?

  • why are we here?
    • creating value for customers
    • by asking why a lot
  • What? Code (software)
  • How?
    • use the best people
    • automated testing
    • constant feedback from customers
    • continuous delivery

When sw complexity increases, productivity decreases

Accidental complexity = complexity not needed

  • unneeded features that the dev. has guessed would be needed, but were not
  • unnecessarily complex architecture

Time report excercise [XXX]

  • Reqs given
  • Excercise: how to start attacking the requirements (formulating solutions)
  • Experience: Where’s the customer?
  • we did Domain modeling based on requirements
  • sketching a user interface can be a good way to start – low tech prototype

The most important factor to reach success in my projects? (A new tool for this)

  • customer collaboration (or good relationship) is key for success

Requirements (a true story)

  • how to write requirements with customer?
  • a solution: story format
  • example:
Story: Register Ticket
As a police
I want to register tickets for crimes
So that the guilty will be punished

Scenario: Happy Case
Given the person 123456-7890 has unpaid tickets of 0 EUR
When the policeman Pelle registers speed tickets for 123456-7890 of 120 EUR
Then 123456-7890 has unpaid tickets of 120 EUR

These can be transformed to automated acceptance tests!

“Ouch, if the system or requirement is changed we will get a maintenance problem!”

  • there should be a maintenance problems
  • this is a huge advantage
  • living requirements, in sync with the system

How to write good stories & scenarios?

  • And whom?
  • do it together!
  • this is customer – developer communication
  • testers can validate the requirements from day one
  • two quotes from a product owner:
    • “Then I have to make up my mind…”
    • “I realize this is good for the programmers…”

Book recommendation: Domain-Driven Design by Eric Evans

Ubiquitous language

  • use the same words in the system, in requirements, in the business
  • names of classes, methods in customer’s own language

Some critical comments about not being able to do this properly in Finnish because of how the grammar works. I think it could be done, and it is not that much harder than in English / Swedish.

Strategic design

  • related systems
  • interfaces
  • domain models of related systems and how to use them
  • domain model design sketches related to scenarios / stories

Demo: Code

  • unit test (to use as an acceptance test?)
    • Scenario name (HappyCase) as the Test method name
    • Given, When and Then parts of the test case code
    • Assertions to the When part
  • Another way: a BDD tool (SpecFlow (for .NET), there are also Cucumber, Robot Framework etc. that you can use)
    • Comment: why to use unit tests when you ave BDD tests?
      • conversation about unit tests breaking when refactoring
      • but what about TDD as a design tool, when you design the code based on loose coupling you should be able to refactor without breaking unit tests
      • comment #2: we need to find the unit that is interesting to test
      • comment #3: running unit tests is usually quick, running BDD tests can take a lot of time
      • comment #4: getting a lot of coverage with BDD tests make the test suite very large. Maybe using BDD + TDD leads to optimal coverage / test run time quota
    • SpecFlow translates Given/When/Then type scenario descriptions to unit test code with the help of (developer-written) templates (or filter files)
      • seems like pretty unusable compared to Cucumber or Robot
    • Unit Test Structure: Given/When part to SetUp, Then parts as different tests (one assertion per test)


Object-oriented domain model does not fit well with a relational database

So why not skip using relational database? NoSQL.

Afternoon sessions consisted of speakers and concurrent open space sessions.

Jani Löthman ja Daniel Wellner: Do You Trust Your Domain Objects?

Domain objects

  • What unit is your data in?
  • if you make your domain object members objects, you can have them handle multiple units
  • you can stop thinking about units when coding
  • i.e. avoid primitive obsession
  • you can use them for data validation also
    • validation in entity, but you don’t always have the entity to use
  • Speakers promote the use of value types (objects)
    • they remove ambiguity
    • they help reduce noise
    • they carry validation rules with it everywhere in the system
    • primitive value can be promoted to value object immediately it enters the system (fail fast)

Using hibernate in mapping domain value types back and forth (db – app -wise).

Format conversion should be done in a separate object (of its own) and validation on the value type object.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s