PPPDDD.2 – Distilling the Problem Domain

Distilling the problem domain is about understanding the problem and its domain  in order to uncover what is relevant and create a model that reflects the domain and solves the problem at hand. In DDD, the activity of doing this is called in Knowledge Crunching.

In order for a useful and accurate model to be created by the developers, they need to put time and effort on fully understanding the problem at hand and its domain. In turn, to really understand the problem, the developers need to have knowledge crunching sessions with the users, stake holders and domain experts.

  • Users: The people that is, or will be, using the application
  • Stake holders: Your client, the one that request the application to be built. They will tell you the broad requirements, the expected inputs and outputs of the application.
  • Domain experts: Anyone with great insight on the details of how the product should work, they can be users, stake holders, product owners, project managers… They will tell you the details of how the application should work and they will be actively helping you to create a useful and accurate model of the problem solution and its domain.

These knowledge crunching sessions are simple meetings, formal or informal, where the domain experts explain the problem at hand and its domain, using a white board, going through use cases and brainstorming on the subject. This will give the developers the information they need so they can create a useful model that accurately reflects the domain and solves the problem.

Knowledge crunching steps

  1. Identify the use cases with the stake holders
  2. Go through each use case with the domain experts, so each use case is clearly understood
  3. Identify bounded contexts, as in “sub applications” that can work more or less independently from the rest of the application
  4. Identify key domain entities in the system
  5. Identify key domain events in the system
  6. Create the model, and iteratively evolve and simplify it as the problem and its domain are better understood and new business concepts come into play

Points 3, 4, 5 and 6 in this process all depend on the first and second points being done correctly. They are the base of all the other points, they define what the business really needs from the application.

Ubiquitous Language

In order for points 1 and 2, of knowledge crunching, to be successful, there must be very good, easy and unambiguous communication between developers, stake holders and domain experts. With this in mind, a common language must be used, the Ubiquitous Language, a shared language rich in domain specific terminology known by all developers, stake holders and domain experts, to be used both when knowledge crunching and within the code itself.

To further facilitate communication between the developers and the domain experts, it is recommended that they work close together, in the same space, so that communication happens at any time and not only during weekly meetings.

Patterns for knowledge crunching

  • Focus on the functionality that is core for the business success:
    • What is hard to use in the current system?
    • What manual processes are castrating the business?
    • What changes would increase revenue or save money?
  • Start from the use cases:
    • What will the users do with the system?
    • What will be the inputs and expected outputs?
  • Ask powerful questions:
    • What is the success criteria for this product?
    • What is the business trying to achieve?
    • Where does the need for this system come from?
    • How will this system give value to the business?
    • More examples in Greg Young blog
  • Sketching
    Use a white-board or paper to sketch visual representations of the concepts while you discuss them with the domain experts, keeping them informal and easy to quickly iterate throughout the conversation.
  • Class Responsibility Collaboration cards
    CRC cards help the team keep the focus and be aware of the business concepts and how they relate to each other. CRC cards contain the following information:

    • A class name, which represents a concept in the domain (subjects and events)
    • The responsibilities of the class
    • Classes that are associated and required to fulfill its purpose

Modeling guidelines

  • Use existing models, which you can find in books or the project documentation
  • Understand what is the intent behind the requirements, as often the requester knows what he wants but doesn’t know what he needs
  • Event storming is an activity to identify the events that can happen in the problem domain, their origin and their side effects
  • Understand the business model, using a Business Model Canvas
This post is part of a set of posts with my personal notes about all the chapters in the book “Patterns Principles and Practices of Domain-Driven Design” by Scott Millett and Nick Tune. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.
Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s