In our practice of domain-driven design, before building anything we collaborate on modeling your organization's activities to form a set of project blueprints, including a vocabulary.

• Role responsibilities capture everybody's responsibilities within the organization or part thereof that the system is intended to handle (ie, the subjects).
• Entity attributes outline the characteristics of the widgets that the organization handles, mainly its products and services (ie, the objects).
• Process maps outline the steps each user undertakes in acting upon entities in order to fulfill their role in the organization's work (ie, the sentences and paragraphs).
• Access policies utilize the various entity attributes to form a set of rules assigned to the various roles. In Engaging OS, this is how role responsibilities and process maps are realized.
• Screen wireframes sketch out the canvases where each user will perform these steps, and the ways to navigate to them.
• A maquette provides guidance for the intended look and feel of the interface.
• A binding narrative tells the story of the project utilizing all the terms generated in the other aspects of the model.

The process maps ensure that the system is focused on delivering the required functionality.

The entity attributes and screen wireframes, in demanding that every facet of the system be labeled, help us communicate about the system. Our communication gets rolling with the binding narrative, which serves as a guide for discussing the project. As Eric Evans explains in his 2003 book Domain-Driven Design:

It is vital that we play around with words and phrases, harnessing our linguistic abilities to the modeling effort, just as it is vital to engage our visual/spatial reasoning by sketching diagrams.

Any and all issues uncovered later during implementation are treated as continuations of the discussion of the model and may modify it and the resulting system. As Evans writes:

These models are never perfect; they evolve. They must be practical and useful in making sense of the domain. They must be rigorous enough to make the application simple to implement and understand.