How to Model with Domo
Toolbox
At the top of the following tool view is user menus as well as modeling views and toolbox. The view is the default, EventStorming model, with toolbar.
Each of the menu options and modeling views are explained next, followed by details of each modeling view and its tools.
Menus and Modeling Views
The menus at the upper right provide user-level options and model views.
| Menu Item | Type | Description |
|---|---|---|
 |
Username | The name of the signed-in user; your user name. In the example, Jody is the username of the user. |
 |
Live Collaboration | Invite other users to collaborate on the model. Thanks what storming means. |
 |
Options | Get help and select options for typing in and viewing the model and model elements. |
 |
Sign Out | Sign out of the current modeling session. |
 |
EventStorming | The default model view, used for EventStorming; toolbar elements explained below. |
 |
Context Map and Topo Architecture | Given two or more subdomains identified in the EventStorming model view, use DDD Context Mapping to show relationships between Bounded Contexts. Along with the Context Map, view the model's architectural topography. It displays contours the between multiple Bounded Contexts and within each individual Bounded Context. |
EventStorming
When the STORM tool is selected at the top right of the user interface, the EventStorming modeling surface is visible. This is the default tool to be selected after sign up or sign in. See the previous image to see the empty modeling surface and available EventStorming element types.
The toolbar to the left contains the modeling perspective switch along with the modeling elements that are used for EventStorming. Note that the colors reflect those typically used for specific element types. An icon is provided for those new modelers and those with color blindness. In order, these are the element types and their use.
| Icon | Element Type | Why Used |
|---|---|---|
 |
Modeling Perspective | Switch between Big-Picture and Design-Level modeling perspectives. |
 |
Event | Indicates an occurrence of some significant business outcome. |
 |
Command | Expresses the intent to perform an application operation, generally with an event as the outcome. |
 |
Policy | Represents some business rule or rules, including validations, calculations, or routing subsequent operations. |
 |
Entity | A unique instance of data that may also provide operations on its data. |
 |
View / Query | Data that is collected as an application view that is queried and displayed to the user. |
 |
User Role | Represents a kind of user in a role or even a specifically named persona (e.g. within a scenario, user story, or use case). |
 |
External System / Subdomain | Relative to the storming model: an external system that makes an impact, such as emitting an event; or a marker for a recognized subdomain within. |
 |
Opportunity | Marks an area of the model that indicates a core business opportunity; includes voting counter to show participant agreement. |
 |
Problem (a.k.a. Hot Spot) | Marks an area of the model that indicates a problem to be addressed; includes voting counter to show participant agreement. |
 |
Filter (Option) | Select modeling element types to see in the model, implying that some may not be seen. |
 |
Compact / Expanded (Option) | View subdomain container elements stacked vertically (compact) or spread horizontally (normal, default). |
The following is a portion of an EventStorming model that, although incomplete, demonstrates a number of model element types.
The above is a "big-picture" model; that is, one that lacks some details and precision. Yet, the modelers have learned enough to identify multiple subdomains within a single timeline. The modelers make divisions using the Domo subdomain container tool with the subdomain name and an indication of its life cycle condition. For example, subdomain containers with a green oval represent new or clean contexts, while the legacy system is marked with a brown oval (brownfield or Big Ball of Mud).
In review of the example model, this table indicates the modeling elements employed and why they are used.
| Element Type | Why Used |
|---|---|
| User Role Client | In the Matching subdomain a client submits a proposal. |
| View/Query Proposal | There is a pre-assembled view that all clients use to submit proposals. |
| Event ProposalSubmitted | Minus details, the event is caused by processing the submitted proposal. |
| Domain Service Pricing Analyzer | Reacting to the Matching subdomain's ProposalSubmitted event, the Pricing subdomain analyzes the proposed pricing using this stateless operation. |
| Policy Time-based Pricing | The time-based business rules for task pricing are the property of the policy. |
| Entity PricingHistory | Tracks the history of one or more pricing analysis outcomes; proposal of rejected pricing is re-submitted with increased pricing. |
| Events PricingVerified and PricingRejected |
Either one or the other is the outcome of pricing analysis. |
| Event PricingAccepted | Assuming PricingVerified from the Pricing subdomain, the Matching subdomain notes the outcome with its own downstream event. |
| Event DoersRecommended | Reacting to the Matching subdomain's PricingAccepted, the Profiles subdomain recommends doers (workers) to perform the proposed tasks. |
| Event CandidateDoersRecorded | Given the Profiles subdomain's recommended doers, Matching subdomain records the candidate doers. |
| View CatalogPages | The Legacy Pricing Catalog system (under the primary timeline) offers a query for obtaining views of catalog pricing for doer task-based services, which is used by the Pricing subdomain. |
The more detail given, the closer the storming session becomes "design level". Think of the above.
Context Mapping
Context Mapping is one of the strategic modeling tools defined by Domain-Driven Design. This tool is used to understand and visualize the dependency relationships between multiple Bounded Contexts and the teams that own them.
The relationships shown in a Context Map are relative to a problem space domain. Teams are generally considered by their peer-to-peer or upstream-downstream dependencies.
The following is a portion of an EventStorming model that, although incomplete, demonstrates a number of model element types.
Consider the common relationships.
| Relationship | Description |
|---|---|
| Partnership | Two teams have a mutual dependency on each other's context to the extent that if either fails, both will fail. The contexts are peers, meaning that there is no ceremony required between expressing needs and receiving due functionality. The winners are those who best coordinate and cooperate. Partnerships can be slower and more difficult due to the complexity of integrated models and schedules. |
| Shared Kernel | Two or more teams share a small, common model, that is blended with their own specialized model. This requires agreement, and is often best used for system-wide standards, such as monetary or others. Note that this is not just a data schema (see Published Language), but a model with both data and behavior (object types). Caution is warranted against overuse or imagining that a reusable library fits the bill. The artifact is a shared, small, model. |
| Customer-Supplier | A team has a dependency on another team's Bounded Context, but the teams are not peers. Rather, the dependent is downstream from the upstream dependency. This makes the downstream team subject to the availability of schema and functionality that meets their specific needs. Addressing special needs is left to the discretion of the upstream team, which may impact the downstream team's timeline and capabilities. |
| Conformist | A downstream team must conform to an upstream model. This dependency is might be a desired choice, but is often determined by the complexity of the upstream model and downstream team's capacity and capabilities. Of course, any changes to the upstream model can/will have an impact on the downstream team, depending on their usage surface area. |
| Separate Ways | A team could potentially integrate with another model, but might decide that the benefit doesn't match the effort required, so the team decides to create their own one-off solution. Care must be taken with respect to DRY, or Don't Repeat Yourself. Note that DRY means "Don't Repeat Knowledge," not "Don't Repeat Code." Knowledge silos are problematic because repetition of captured knowledge in a business software context might cause deviation in one or more repeating models. When DRY as in knowledge is a certain factor, consider integration instead. |
| Anti-Corruption Layer | A downstream team has both the capacity and capabilities to take a highly defensive posture in consuming upstream model. The upstream model is often complex and poorly designed, but the downstream model can still benefit by translating even clean models to their own language. The downstream creates a set of translation components that render the upstream model to a specific design that adheres to their own model design. |
| Open-Host Service | A model has a well-designed API that enables one or more other teams to confidently and reliably perform operations. The consumed API is not automatically in an upstream position, which means that the majority of the previous and following relationships apply. That is, any consuming team can find themselves in a variety of circumstances, which will determine how the model behind the API is used. See also Published Language. |
| Published Language | A set of well-designed schema specifications—possibly considered a single specification—are provided for data exchange between Bounded Contexts. A Published Language is often paired with and Open-Host Service. A specific schema set can be an standard of the following proportions: international, national, industry, inter-business, intra-business, and context/model/team. |
| Big Ball of Mud | Systems are often implemented in monoliths without any intentional design and architecture, and have been long subjected to expedient change. There are generally no efforts or even recognition of the complex problems that will be at play, even quite early in the software life cycle, and thus are left to chance. Technical debt rises continually and is seldom paid. The tangle that ensues is often compared to a large, muddy, amorphous blob, or otherwise, a brown field of software. In time nearly zero changes can be made without regression, which cause system releases to stagnate. |
Topo Architecture Modeling
Each Context Map additionally presents an architecture view of collaborating Bounded Contexts, which reveals the contours of how multiple Bounded Contexts collaborate. This mixed-in view is named Topographic Architecture Modeling.
Some examples follow. To illustrate the use of the Topo Architecture view, the following limited EventStorming Pricing model is assumed.
Since the Topo Architecture is accessible in the Context Map, the user interface is the same that you see above in the previous Context Map section. Here's a close-up of the Pricing Context. In particular, notice the properties icon at the top and the drop-down arrow at the bottom.
Click the properties icon at the top of Pricing. You'll see the following properties dialog. You can select the kind of Bounded Context it is: Core, Supporting, or Generic. You can enter other information, such as the names of the subdomain, business capability, description, and team members.
Select Core and enter some information, such as the description and the team members that work on the context; just enter some given/first names. By clicking outside the properties dialog, it is dismissed. The properties have been persisted.
Next, consider the use of the topographic model element view. Keep in mind that the Pricing model is limited to a single element, PricingVerified. This implies that there will be only two elements in the topographic model view, the one incoming ProposalSubmitted event from Matching, and the other is the outgoing PricingVerified event shown here.
The topographic summary view is seen in the next image. To the left you see the model elements that drive it, those inside the domain model in the center, and those to the right that it uses to drive results outside.
On the summary view, click the drop-down arrows for each of the non-zero element types. In this example, the non-zero element types are Incoming Events and Outgoing Events, each with one element.
If you now return to the EventStorming view of the model and enter some new elements to Pricing, they will be reflected in the Topo Architecture view. Consider the following elements that augment the Pricing model.
What is reflected by this new model? The following elements were added to the Pricing model:AnalyzePricing, PricingAnalyzer, PricingHistory, and PricingVerified.
| Element | Description |
|---|---|
| AnalyzePricing | The incoming Matching event, ProposalSubmitted, is adapted to the command AnalyzePricing. This is a simple anticorruption technique. |
| PricingAnalyzer | The AnalyzePricing command is executed on a Domain Service, PricingAnalyzer. |
| PricingHistory | When the PricingAnalyzer Domain Service has verified or rejected the offer price, it hands off the result to the PricingHistory, which is an Aggregate. |
| PricingVerified | The PricingHistory Aggregate records the pricing analysis outcome and emits either the PricingVerified event or the PricingRejected event. |
These Pricing model additions are reflected in the Topo Architecture view. Switch back to the Context Map view, which also contains the Topo Architecture view, and once again click the Pricing drop-down icon.
Giving more thought to the model, the team has not yet determined the business rules for pricing analysis. They don't currently have immediate access the the right domain experts, so they decide to include a policy to the EventStorming model to indicate a placeholder for the necessary rules.
As it previously happened, the addition of the Time-based Pricing Policy to the EventStorming Pricing model is reflected in the Topo Architecture view. Once again, switch back to the Context Map view, click the Pricing drop-down icon, expand each of the non-zero element types, and you will see the following.
As more modeling decisions are made and declared in the model, the majority will be displayed on the Topo Architecture model view. For example, when adding one or more View (green element) on the EventStorming view, it will be reflected in the topographic view as a Query on the left side and a Projected Views on the right side.
Return often to discover what's new.
developed by Kalele.