Skip to content

Latest commit

 

History

History
37 lines (25 loc) · 2.83 KB

step-1-aquire-domain-understanding.md

File metadata and controls

37 lines (25 loc) · 2.83 KB
Raw

VDAD Step 1: Aquire Domain Understanding

TL;DR: Apply domain-driven practices to analyze the domain with its core, generic and supporting subdomains1 and acquire knowledge about them. Establish a common vocabulary, the Ubiquituous Language1 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 Storming2 or Domain Storytelling3 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 Subdomain1 or already per Bounded Context1 (but not necessarily in the first iteration)
  • Workflows that illustrate business processes, elicited with domain-driven practices such as Event Storming2 or Domain Storytelling3
  • Use Cases and/or User Stories, as summarized in the Design Practice Repository (DPR)4
  • Already known Non-Functional Requirements (NFRs) and technical/organizational constraints
  • Additional artifacts depending on project context and needs

Supporting Tools

  • Egon.io for Domain Storytelling3
  • Whiteboards or digital tools such as Miro for Event Stormings2
  • Context Mapper for domain modelling, use cases, user stories

Process Navigation

Footnotes

  1. Domain-Driven Design Reference, Eric Evans, https://www.domainlanguage.com/ddd/reference/ ↩ ↩2 ↩3 ↩4

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

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

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