Journal of Distributed Software Engineering, Architecture and Design
User Journey, User Story vs Domain Story: What’s the difference?
<div class="cs-rating pd-rating" id="pd_rating_holder_1819065_post_1908"></div>
<p class="wp-block-paragraph">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?” </p>
<p class="wp-block-paragraph">Here is a quick look at differences:</p>
<ul class="wp-block-list"><li><strong>User journey story:</strong> Is a technique for describing how the <strong>user interacts </strong>with our business (and business systems) <strong>over time</strong> to realise an end goal</li><li><strong>User story</strong>: Is a technique to describe specific functions the user must perform at each stage of a journey. It describes <strong>how a user interacts</strong> with our business or business system at a <strong>point-in-time</strong></li><li><strong>Domain story</strong>: 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 <strong>what </strong>happens to our <strong>business information systems when a user interacts</strong> with them</li></ul>
<figure class="wp-block-image size-large is-resized"><a href="https://alok-mishra.com/wp-content/uploads/2021/06/alokmishra-user-story-vs-domain-story.jpg"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/alokmishra-user-story-vs-domain-story.jpg?w=1024" alt="" class="wp-image-1910" width="828" height="544" /></a></figure>
<h2 class="wp-block-heading">So what?</h2>
<p class="wp-block-paragraph">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</p>
<h2 class="wp-block-heading"><strong>Summary</strong></h2>
<p class="wp-block-paragraph">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. </p>
<p class="wp-block-paragraph">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 </p>
<p class="wp-block-paragraph">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?)</p>
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?)
Alok brings experience in engineering and architecting distributed software systems from over 20 years across industry and consulting. His posts focus on Systems Integration, API design, Microservices and Event driven systems, Modern Enterprise Architecture and other related topics
View all posts by alokmishra