While running DDD workshops with clients, I have had this question come up several times – “What is the difference between a Domain story vs a User Story?”
Here is a quick look at differences:
- User journey story: Is a technique for describing how the user interacts with our business (and business systems) over time to realise an end goal
- User story: Is a technique to describe specific functions the user must perform at each stage of a journey. It describes how a user interacts with our business or business system at a point-in-time
- Domain story: Is a technique for capturing the behaviour and actions of the user (actor) with our systems and the deeper impact of this action to our systems and its sub-systems. It is a way to describe what happens to our business information systems when a user interacts with them

So what?
Recognising these differences should help when domain storytelling. We do domain storytelling in our DDD journey to understand how we model our software better to handle specific business contextsd
Summary
The process of using Domain Driven Design (DDD) to model software and software interactions compared to other design techniques (system oriented, layer oriented, bottom-up etc) relied on foundational techniques such as Domain Storytelling, Context Mapping etc.
Domain storytelling is key to understanding what happens to our software system as user’s interact with it as compared to User Story which might consider only the superficial aspect of a user interaction (Portal, Mobile or CRM) and leave the rest as ambiguous technical stuff a solution team needs to figure out
As a DDD practitioner, I love the domain storytelling aspect as it builds a view of how user interactions are facilitated by software (how did information get here in the first place? what are the pre-conditions?) and the impact to the state of the information in our systems as the effect of the interactions propagate (when a user submits something what happens next?)