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
- Identify the use cases with the stake holders
- Go through each use case with the domain experts, so each use case is clearly understood
- Identify bounded contexts, as in “sub applications” that can work more or less independently from the rest of the application
- Identify key domain entities in the system
- Identify key domain events in the system
- 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
@hgraca 
Hello, good post, I enjoyed the reading. Some questions arise:
Are the knowledge crunching steps you describe kindof a methodology to build the product? I think that DDD isn’t a methodology, it is an approach, a philosophy, for building software. In fact maybe what DDD encouraged would be an inside outside steps, i.e., first domain model, then use cases, as the domain is the most important thing for DDD, you first model the domain and then expose it ti
Which technique do you use for step 1 & 2 (identifying and understandong use cases)? Have you ever used «user story mapping» (Jeff Patton). I think it would fit there, but working with user stories instead of use cases. Also BDD could be use for testing concrete scenarios.
LikeLike
I have used «event storming» (Brandolini) a few times and it worked out very, VERY well. I never used BDD, but I feel that having good story acceptance criteria will achieve the same result with less effort, although I do see the advantage of having those acceptance criteria explicit as BDD tests.
LikeLike