Skip to content

Latest commit

 

History

History
125 lines (76 loc) · 5.99 KB

README.md

File metadata and controls

125 lines (76 loc) · 5.99 KB
Raw

< back to 02 Coffee Shop Scenario

Roles, Commands and Events Mapping

Key Business events in the coffeeshop

💡 Tips:

When capturing Events in business scenarios, be aware that domain experts may or may not be technical. Use ubiquitous language to communicate.

  • Events discovering process should not be technical
  • Focus on the core business value
  • Figure out trigger and result

An example of the immutable events occurred:

  • Menu offered
  • Ordered 2 cups of Americano
  • Completed payment
  • Received receipt
  • Seat occupied
  • Order received
  • Coffee prepared
  • Customer left premise
  • Cleaned up table

You can always arrange these events sequentially in the timeline where it occurred.

Commands and Events mapping

Now, let's add in Commands. Commands are triggers, actions or intention that result in the event. Label them with a blue sticky note. Use present tense for Commands.

Roles

As you explore these events, think about the key players involved in these Events. We call them Roles. Roles can represent a human or a system. Use a yellow sticky note to represent them. You should end up with something as follow.

The roles involved would be:

  • Customer
  • Cashier
  • Barista
  • Waiter

Commands can be triggered by another event, person or even systems, both internal or external.

We shall call the interface between the Command and Event as a "(?)" for now. This is a key element in serving the requests, process it internally, and once the process finished, results in the Event.

Sometimes, "(?)" could also communicate with other business capability provider, or external system with the Event as an outcome.

Exceptions or risky events

Throughout the events exploration journey, there will be many different sticky notes pasted on the wall and not all events will have a smooth flow.

To do it in a cost-effective way, take the most risky journey and explore the exceptions. You can find more events from this and extend the journey to enrich the business flow.

Re-think solutions to serve risky events

Represent these failure scenarios with red sticky notes. For example, think about the consequences in the business flow in the coffee shop scenario.

  • What if the customer ordered coffee without giving a table number?
  • What if the barista made a wrong order?

Regardless if it's a failure or mistake, the customer experience will be impacted. There is a need to re-think about these issues to sieve out further actions to prevent or solve these issues.

Although not essential, this step could help you to handle business scenario which you were not familiar with before.

Replay the scenarios forward and back, each time dropping off some of the questions, risk or exceptions posted and the pieces will start to grow into a more elaborate story.

Aggregate

Until now, you may have realized that the central element "(?)" provides business capability and owns the responsibility to accept or reject Commands from the Role. This is called "Aggregate".

However, at the early stage, encourage participants to focus on gathering Events and Commands. Focus more on building the relationship between these objects. An Aggregate will usually create the most confusion as participants try to grasp its concept. Try to pin them on a yellow sticker and leave the name empty at the moment, maybe just mark it as a question mark. Try to defer naming until team has fully knowledge of the domain.

Aggregate Naming

Another example for IT guy outsourcing, project management

Aggregates are logical groups of Commands and Events that make sense to think about them as a single unit within the business process.

With more of the scenarios being played out, the name for the Aggregate should fall in place naturally.

Here are some examples of Aggregate naming convention:

  • By Nouns
  • By Gerunds (Verb with - ing)

No matter which convention you favor, remember to present the "ability" of the aggregate, that means traverse each Command the Aggregate is received, and make sure each event occurred is reasonable.

Bounded Context forming up

With more and more Aggregates being captured, you may find that several Aggregates are cohesive, others are not. There is a simple pattern to help you form up the boundary to have a clear bounded context.

  • Command A is fired and it causes Event A
  • Event A provides information View A
  • View A is also needed while doing a condition that uses Command B
  • Command A and Command B might be good to be in one module together

Circle these cohesive aggregates together, the boundary is naturally established.

While you figure out several bounded contexts, there are some co-relationships between each other, some bounded context play the upstream role, some of these play the downstream role. From Eric Evans' perspective, there are 9 types of corelationships.

Context Maps could reflect the collaborative or even organizational teams' relationships between different Bounded Contexts in your systems.

It is sometimes worth to do a "Bounded Context Mapping" which can uncover what are some of the dependencies, what's the impact scope when upstream (e.g. API contract) has changes, and how to prevent harmful downstream impact of it.

Recommend to read Bounded Context Mapping - by Domain Driven Design Taiwan Community - Eason Kuo for more details.

Next, let's look at how we can translate all these into modeling into development work.

Next: 04 Modeling and Development >