Value-Driven Analysis and Design (VDAD)

VDAD Process | Practices | Why VDAD? (User Stories) | Tools | Background | Glossary

VDAD Step 1: Aquire Domain Understanding

TL;DR: Apply domain-driven practices to analyze the domain with its core, generic and supporting subdomains¹ and acquire knowledge about them. Establish a common vocabulary, the Ubiquituous Language¹ of the domain.

Goal and Approach

This step ideally involves all project stakeholders from customers, business experts, users to developers. The goal of this first step is to aquire a common understanding between business people and developers/engineers. A common language shall be spoken so that misunderstandings and the need for translation are reduced.

This step usually, at least in the first iterations, produces analysis results on a higher level. A Domain Model must, therefore, not already use tactic DDD patterns and is not ready to be implemented. An Event Storming² or Domain Storytelling³ can also be considered a viable alternative to a Domain Model at this stage. It is just important that you model the established understanding. In domain-driven terms: you probably model the real world - as it is - in this step; meaning you are modelling Subdomains (object-oriented analysis), but not Bounded Contexts yet (object-oriented design).

Inputs

The domain knowledge of the experts and existing business processes are the input to this step.

Outputs

The knowledge is written down and carved into:

• A Domain Model, potentially per Subdomain¹ or already per Bounded Context¹ (but not necessarily in the first iteration)
• Workflows that illustrate business processes, elicited with domain-driven practices such as Event Storming² or Domain Storytelling³
• Use Cases and/or User Stories, as summarized in the Design Practice Repository (DPR)⁴
• Already known Non-Functional Requirements (NFRs) and technical/organizational constraints
• Additional artifacts depending on project context and needs

Supporting Tools

• Egon.io for Domain Storytelling³
• Whiteboards or digital tools such as Miro for Event Stormings²
• Context Mapper for domain modelling, use cases, user stories

Process Navigation

• Complete VDAD Process
• Next Step (2): Identify Stakeholders

1. Domain-Driven Design Reference, Eric Evans, https://www.domainlanguage.com/ddd/reference/ ↩ ↩² ↩³ ↩⁴

2. http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html ↩ ↩² ↩³

3. Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software, Stefan Hofer, Henning Schwentner, https://domainstorytelling.org/ ↩ ↩² ↩³

4. Design Practice Repository (DPR), Olaf Zimmermann and Mirko Stocker, https://github.com/socadk/design-practice-repository ↩

This work is open source and licensed under a Creative Commons Attribution 4.0 International License. Open on GitHub.