User stories have, in a way, bridged the gap between technical teams and the Business: we understand what you want and why; we speak the same language!

On the architecture/design  side, this can be still be a black box for the Business or even for the scrum master and product owner: yes we get the idea but cannot really comment…

Looking at Domain Driven Design (Domain Model Principles), the tech team is going to model their “architecture” while interacting with the customers/users (PO) and use the same words used by the “business” to model their design.

Concretely, as the customers describe their business flows in front of the tech team, the tech team map out the flows to a model so the customers can understand how the system will handle these flows and spot any issues, missing constraints and requirements.

One great benefit from an agile point of view is that this is another “tool” to use to increase interactions between tech teams and the business to implement the right solution.

The use of ubiquitous language is key as “Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software – hence the need for it to be rigorous, since software doesn’t cope well with ambiguity.” (see

Short introduction:

Video:  (quite good, some very good examples to see who it works) (From Eric Evans – DDD: “putting the model to work” – a good example!)  (very theoretical at the beginning)