Requirements to Domains
Breaking down the requirements into Domains, etc.
We need to break down the domain and decompose into small pieces:
- Use Cases
- Functional Requirements
Several ways to analyse the domain, for example following the steps:
- Requirements and modelling
- Identify User Stories
- Identify nouns
- Identify verbs
We start by writing the functional requirements (what the system must do, the actions and operations it should perform), for example for an e-commerce site:
- List products
- Filter products by brand or category
- Add products to the shopping cart
- Apply discount coupons and show the total cost for all items in the shopping cart
- Checkout the shopping cart and create an order
- List order history and old orders
From here we can use these functional requirements to create the associated use cases:
- As a user I want to list products
- As a user I want to filter products by brand and category
- As a user I want to add products to the shopping cart so that I can checkout later
- As a user I want to apply discount coupons and see the total cost for all items in the cart
- As a user I want to checkout the shopping cart and create an order
- As a user I want to list my historical orders and order items
- As a user I want to login to the system as a user and the system should remember any items placed in my shopping cart
Now expand the stories as appropriate and highlight the verbs and nouns in those stories:
- As a user I want to list products
- As a user I want to filter products by brand and category
- As a user I want to see the supplier of a product in the product detail screen with all details of that product
- As a user I want to be able to add products that I want to purchase into the shopping cart so I can check out
- As a user I want to see the total cost for all the items that are in my shopping cart so that I can see if I can afford to buy them
- As a user I want to see the total cost for each the items in my shopping cart so that I can verify the price
- As a user I want to be able to specify the address for delivery
- As a user I want to be able to add a note to the delivery address to provide special instructions
- As a user I want to be able to specify my credit card information during checkout so I can pay
- As a user I want the system to tell me how many items are in stock so that I know how many items I can purchase
- As a user I want to receive an order confirmation email with an order number so that I have proof of purchase
- As a user I want to list my historical orders and order item history
- As a user I want to login to the system as a user and the system should remember any items placed in my shopping car
Now extract the nouns and verbs from these user stories
We want the nouns that become the main objects rather than attributes:
- Customer
- Order
- Order Details
- Product
- Shopping Cart
- Shopping Cart Items
- Supplier
- User
- Address
- Brand
- Category
This will help us to define sub domains and bounded contexts
With the verbs we can understand the communication between domains:
- List products (applying to paging)
- Filter products by brand, category and supplier
- See all product information in the details screen
- Put products into the shopping cart
- See total cost for all items in the shopping cart
- See total cost for each item in the shopping cart
- Checkout order with purchase steps
- Specify delivery address
- Specify delivery note for the delivery address
- Specify credit card information
- Pay for the items
- Tell me how many items are in stock
- Receive order confirmation email
- List the order and details history
- Login the system and remember the shopping cart items
Using this information we can create an object responsibility diagram for the application:
This allows us to consider the object responsibilities. Remember the responsibilities go on the object rather than the actor, so for example although the customer adds items to the shopping cart, it is the shopping cart that has the task of actually adding the item to itself.
From this we find the object interactions and responsibilities, allowing us to now work on the actual & potential microservice decomposition.
