humank / ddd-practitioners-ref Goto Github PK

EventStorming workshop, this is a hands-on workshop. Contains such topics: DDD, Event storming, Specification by example. Including the AWS product : Serverless Lambda , DynamoDB, Fargate, CloudWatch.

License: Other

Java 95.81% Gherkin 0.31% Shell 3.04% Dockerfile 0.84%

aws eventstorming ddd serverless microservices container ecs lambda fargate eventbridge

ddd-practitioners-ref's Introduction

Domain-Driven Design Practitioners Reference

Under Construction -

Appreciate having your support on building this workshop, hope this workshop is useful & meaningful for you. In order to well organize all of the contents for DDD practitioners reference, the workshop will be refactored to cover wider topics with a more complex business scenario sample. Plan to release new content before the end of 2021, stay tuned.

In this ddd-practitioners-reference, you will learn more than classic Domain-Driven Design Strategic design and Tactical design patterns. DDD is good to approach decision makers to align business goals among diversity stakeholders in different BU.

When learning a series of methodology would always bored ourself and lot passion on the unlimited learning journey, so i'll walk you through a bsuiness case to practice the following methodologies/approaches to get familiar in using DDD to design solutions.

So, this guide will cover below topics whaich are what I learned from WW communities (ddd_eu, virtualddd) and awesome ddd-practitioners experience.

Outline:

A sample business story - Trip Service
Awaren businesss context by Wardley Maps
Kowing your key stakeholders - Impcat Mapping
EventStorming
Bounded Context Canvas - founded by Nick Tune
Aggregate Design Canvas (*) - founded by Kacper Gunia
Aggregate Canvas (*) - founded by Arthur Chang
Example Mapping
Specification by Example
Implement DDD Tactical pattern in Clean Architecture with Spring boot framework - refer to awesome-trip
Integrate with AWS cloud native offerings

Event Storming

What is Event Storming?

Event Storming is a rapid, lightweight, and often under-appreciated group modeling technique that is intense, fun, and useful to accelerate project teams. It is typically offered as an interactive workshop and it is a synthesis of facilitated group learning practices from Gamestorming, leveraging on the principles of Domain Driven Design (DDD).

You can apply it practically on any technical or business domain, especially those that are large, complex, or both.

Whom is it for?

Event Storming isn't limited to just for the software development team. In fact, it is recommend to invite all the stakeholders, such as developers, domain experts, business decision makers etc to join the Event Storming workshop to collect viewpoints from each participants.

Event Storming Terms

Reference from Kenny Bass - https://storage.googleapis.com/xebia-blog/1/2018/10/From-EventStorming-to-CoDDDing-New-frame-3.jpg

Take a look on this diagram, there are a few colored sticky notes with different intention:

Domain Events (Orange sticky note) - Describes what happened. Represent facts that happened in a specific business context, written in past tense
Actions aka Command (Blue sticky note) - Describes an action that caused the domain event. It is a request or intention, raised by a role or time or external system
Information (Green sticky note) - Describes the supporting information required to help make a decision to raise a command
Consistent Business Rules aka Aggregate (Yellow sticky note)
- Groups of Events or Actions that represent a specific business capability
- Has the responsibility to accept or fulfill the intention of command
- Should be in small scope
- And communicated by eventual consistency
Eventual Consistent Business rules aka Policy (Lilac sticky note)
- Represents a process or business rules. Can come from external regulation and restrictions e.g. account login success/fail process logic.

Event Storming Benefits

Business requirements can be very complex. It is often hard to find a fluent way to help the Product Owner and Development teams to collaborate effectively. Event storming is designed to be efficient and fun. By bringing key stakeholder into the same room, the process becomes:

Efficient: Everyone coming together in the same room can make decisions and sort out differences quickly. To create a comprehensive business domain model, what used to take many weeks of email, phone call or meeting exchanges can be reduced to a single workshop.
Simple: Event Storming encourages the use of "Ubiquitous language" that both the technical and non-technical stakeholders can understand.
Fun: Domain modeling is fun! Stakeholders get hands-on experience to domain modeling which everyone can participate and interact with each other. It also provides more opportunities to exchange ideas and improve mindsharing, from various perspective across multiple roles.
Effective: Stakeholders are encouraged not to think about the data model, but about the business domain. This puts customers first and working backwards from there, achieves an outcome that is more relevant.
Insightful: Event Storming generate conversations. This helps stakeholders to understand the entire business process better and help to have a more holistic view from various perspective.

Event Storming Applications

There are many useful applications of Event Storming. The most obvious time to use event storming is at a project's inception, so the team can start with a common understanding of the domain model. Some other reasons include:

Discovering complexity early on, finding missing concepts, understanding the business process;
Modelling or solving a specific problem in detail;
Learning how to model and think about modelling.

Event Storming can also help to identify key views for your user interface, which can jump start Site Mapping or Wireframing.

Let's get started with a quick example to demonstrate how to run a simple Event Storming.

Next: 01 Hands-on Events Exploring >

ddd-practitioners-ref's People

Contributors

Stargazers

Watchers

Forkers

cenxui abeyasuakisama fallingstar1204 agiledon ptabc silvav kokokuo justericgg xibeiwind semurat chaitanyaphalak evangwt docxu fongx777 kevin-penn neobradley comdaze soyunemilio github112017 a60814billy neochen-aws totorochina zorrofox zjutdp xuejiaozhang qinnnyul jame2408 harrishepeng till0061 tanmay-solanki river0825 zhiguohe lzw2006 jangocheng mingsc rayhero cherrylouis mihaibogdaneugen barissonmez howardgod wlucjan tianqiongenze codeya1024 zscomehuyue daikuei garrychen-site uangguan maniacs-oss zeroreturn tanandy bukajsytlos elchesco woodyj heejonglee-aws iron-eater pathway-to-system-analysis-and-design etherealy jerry80409 fabiosantos-mtt ricotoothless code4t2 cquirosj cgb-ddd thecloudranger zhoyou luong-komorebi ichiranakita xiafeicn jsenjobs zhchlmm ibrahimcesar alexrogalskiy zhongziqiu gspindev viniciusstroher coderstudio-dev dh30607 joyce725 wushian jjiinngg iq-scm mateon01 jabrena alexlianghu patrickathaeger crisnguyen92

ddd-practitioners-ref's Issues

Do not expose public setters on Aggregate root

When doing the order create instruction, there are whole bunch of setters running there.
try to use a business-intention method to wrap up the creation detail, such as
Order purchased = Order.create(DTO);
rather than --->
Order purchaseOrder = new Order();
purchaseOrder.setDrinkHere(orderDTO.isDrinkHere());
purchaseOrder.setItemName(orderDTO.getItemName());
purchaseOrder.setPrice(orderDTO.getPrice());
purchaseOrder.setQuantity(orderDTO.getQuantity());
purchaseOrder.setSeatNo(orderDTO.getSeatNo());

Some problems of Coffeeshop-requirements

咖啡店內

當客人在店內點咖啡時，咖啡溫度需要維持在70度，便於客戶飲用，若客戶是外帶則會需要把製作溫度調高到90度

There are two kinds of temperature need to be considered: brewing temperature, serving temperature. Which one did you refer? I think the serving temperature is the answer, but do we need to consider about the brewing temperature?
FYI, Are You Serving Coffee at the Ideal Temperature?
-> Espresso brewing temperature: 88°C-98°C

每一份現煮咖啡我們是義式咖啡的製作方式，每一份濃縮咖啡我們稱之為一個 Shot

What is the size of one shot?
FYI, Espresso wiki - shot variables:
The size can be a single, double, or triple, using a proportional amount of ground coffee, roughly 7 (25ml), 14 (50ml), and 21 (75ml) grams

盛上述咖啡品項基本單價小杯分別為: 120, 80 , 100, 130, 140 .. 每一杯的飲料大小往上加一級則多加20元

Typos, it should be 80, 100, 120, 140

當有任何一個原物料的庫存低於30%，需要通知咖啡師與櫃檯進行補貨，可以通過簡訊、email，而真正去購買原料的是由櫃檯人員去負責

買回來的原物料讓咖啡師確認品項狀態與數量後入庫

希望未來可以有個可視覺化的呈現頁面去看到原料使用狀態、每月熱銷排行、每週熱銷排行

每一次補貨都將該物料補到100%，並且需要在3天內到貨完成

I think the 12th, 13th, 14th(not sure), 15th item belong to "進貨原物料"

進貨原物料

購買牛奶時會需要提供低脂牛奶 (Low-fat Milk)或者豆奶(Soy Milk)

This one should sit in "提供客製化體驗需求"

製作咖啡

美式咖啡 - 製作成分為 1 shot 濃縮咖啡與水

How much water do we need?
Take 美式咖啡 as reference, I think 1:12 is a candidate.

Replace CloudWatch Event by Amazon Event Bridge

Due to there is still some concurrent event put/get limitation on CloudWatch Event, it is better to leverage Amazon Event Bridge to be the Event pipe, to orchestrate or publish events to other appropriate AWS messaging services.

Re-module this project

In order to make this sample more flexible to deploy on serverless architecture and container-like architecture. It's mandatory to modularize the whole project into different modules, separate the business core logic, and leave the infra, persist, communication frameworks into different module as needed.

re-write function with Quarkus framework

In order to have great speed experience on cloud native java, migrate current tech stack into Quarkus framework. That will benefit from standard Java EE spec and have fastest boot up time.

Easy to deploy to AWS Lambda custom runtime , just re-compile the artifact with native-image
Easy to deploy to AWS container service, push onto ECR and have fully integrated functionality on AWS

Menu Proposal

1 shot: 20g -> 1oz: 30 ml
dry foam (only for cappuccino): more foam less milk
wet foam (only for cappuccino): less foam more milk

Item / size	size	price	recipe
Espresso / Solo	30ml	60	1 shot (30ml)
Espresso / Doppio	60ml	80	2 shot (60ml)
Caffe Americano / Short	240ml	80	1 shot (30ml) + 210ml water
Caffe Americano / Tall	360ml	100	1 shot (30ml) + 330ml water
Caffe Americano / Granti	480ml	120	2 shot (60ml) + 420ml water
Caffe Americano / Vanti	600ml	140	2 shot (60ml) + 540ml water
Caffe Latte / Short	240ml	100	1 shot (30ml) + 210ml milk (with a little foam)
Caffe Latte / Tall	360ml	120	1 shot (30ml) + 330ml milk (with a little foam)
Caffe Latte / Granti	480ml	140	2 shot (60ml) + 420ml milk (with a little foam)
Caffe Latte / Vanti	600ml	160	2 shot (60ml) + 540ml milk (with a little foam)
Cappuccino / Short	240ml	100	1 shot (30ml) + 105ml milk + 105ml dry/wet foam
Cappuccino / Tall	360ml	120	1 shot (30ml) + 120ml milk + 120ml dry/wet foam
Cappuccino / Granti	480ml	140	2 shot (60ml) + 210ml milk + 210ml dry/wet foam
Cappuccino / Vanti	600ml	160	2 shot (60ml) + 220ml milk + 220ml dry/wet foam
Cappuccino / whipped cream	20 ml	+20

Other ideas:

通常咖啡店如 Starbucks 不會賣到小杯 (比例比較難調)
Dry Foam 是從牛奶發泡而來，沒有規定一定或最小的牛奶量才能製作，所以「需要2杯牛奶」可能不太好調配。
Whip Cream 通常是像配料一樣加上去，不用特別再製作

References:

Domain Events publish for cloudwatch event
Add a DTO for incoming request body translation
pass the DTO into Domain Service (a.k.a add a OrderService)
OrderService deal with DTO, leverage Order entity
publish event from OrderService
Add a Repository for Order data in DDB

should remove node_modules in root directory

In general, we don't put node_modules to SCM, because it can restore by npm install command.

By the way, I only see package-lock.json in project root directory, and package.json is missing. That weirds me out.