Turning requirements into FlexStudio design
By now, you should have understood following concepts,
- 1.What are modules and features in FlexStudio?
- 2.What are the components of API design in FlexStudio?
These two concepts are covered in previous two sections.
A quick recap: A feature is an API. And modules are logical grouping of APIs. The logical grouping depends on the domain design approach you take. FlexStudio is agnostic to any design approach.
In this section, we will take a deep dive into how to turn application requirements into FlexStudio feature and module design.
We will take a simple example of a modular monolithic e-commerce site. Let us assume that you have been given a requirement where the application is divided into business modules and for each module some features are specified.
We will see how to it is very easy to convert this kind of requirement into Flexbase modules and features. So, let's get started.
The diagram above shows the summary of a typical business requirement of a simple e-commerce site back-end.
This application has 5 business modules - Order, Order Delivery, Order Returns & Pick up, Product and Product Category.
Can there be more modules? Or, can 'Order Return and Pick-ups' be two different modules? Or, can you spin out 'Shopping Cart' as another module from 'Order'? Yes. This can be done.
Let us assume that this is an initial requirement given to you. You will see that if you need to create more modules or reorganize features, it is easy to do so using FlexStudio. This is called refactoring.
Refactoring is an important concept. Ability to reorganize / refactor features during initial stages of application design, helps you iterate the designs fast. This obviously has big impact on the later stages of the development when changes can be very costly.
The advantage of FlexBase is refactoring of code is easy in any stage of development. So changes will not be costly at any point.
Let's get back to the requirement. If you look at the requirement image, for each module the corresponding features are listed. For example, the features in 'Order' module are - add item to shopping cart, remove item from shopping cart, confirm order for COD, make payment, accept payment, etc.
As you have seen earlier, these feature are nothing but APIs. Let us look, how easy it is to turn these features into API design in FlexStudio.
We will do it for two features in the Order module. In the sample application section, design of all the features will be listed.
First, let's pick up a simple feature - "Add Item/s to Shopping Cart".
This is a simple feature. In this feature when an item is added to a shopping cart by user, it is expected that it leads to creation of an item record in the cart in the database.
(Note: for simplicity we will consider a stateless application design. So cart state management is happening in database. These kind of decisions are taken by architects. From FlexStudio design perspective this is not important. FlexGen, the architect tool will allow for architect level decisions. We will look at it later.)
At this stage, you don't need to bother about the structure of the cart record or cart line item records or how they are organized in database. This is a detail for implementation and domain design. You are simply assuming that some sort of persistence takes place when you add an item to shopping cart. This is apparent from the name of the feature.
You must appreciate one point at this stage, that FlexStudio is allowing you to design an API without you worrying about the infrastructure, implementation and domain details. Yet, you can be very sure that Flexbase will implement everything perfectly.
With the information available, you can specify following components of Add Item to Shopping Cart API:
- 1.Action type is POST
- 2.Starting point is a user form (user intent is: Want to add item/s to cart)
- 3.The command is AddItemtoShoppingCart
The diagram below in FlexStudio covers these 3 components
Another point specified in the requirement is - there needs to be an IsStockAvailable check before the item is added to the cart.
In FlexStudio, there is plugin sidebar on the right hand-side where you can create the validation. The diagram below shows how you can add this validation IsStockAvailable.
One more component has been added to the API.
So the API structure now as follows,
- 1.Action type is POST
- 2.Starting point is a user form
- 3.The command is AddItemtoShoppingCart
- 4.There is a validation IsStockAvailable
As you can infer, the domain event taking place in the application is the addition of an item to the cart. Therefore, the event message that needs to be declared is, ItemAddedtoCart .
Are there any other systems or subsystems that are interested in subscribing to this event? From the requirements you see there are none. So your API design is complete. For example, there is no requirement which says when the item is added to the cart enable a discount. So, the API definition stops here.
In the end, based on the requirement, you have 5 components in this API:
- 1.Action type is POST
- 2.Starting point is a user form
- 3.The command is AddItemtoShoppingCart
- 4.There is validation IsStockAvailable
- 5.There is single event message ItemAddedtoCart
The diagram below shows the completed API in FlexStudio
Let's look at a more complex feature this time. Confirm Order for COD
Let us assume following requirement is given for this feature,
"When a user confirms the order by clicking on confirm-order button with cash-on-delivery option, notify delivery team about the required delivery and notify the customer that the item has been shipped. Check stock availability, shopping address validity and eligibility of items for COD before confirming the order."
This is a simple requirement for Confirm Order for COD feature. The main domain event is Order Confirmation for COD. There are 3 checks before the order is confirmed and notifications need to be sent once the order is confirmed.
In Flexbase, this requirement can be extended to any complexity without much change. This is where FlexStudio shines in it's simplicity and power. Let's look at "notify delivery team" part for instance.
Depending on the size of the business, the implementation of this API can change without making any change in the definition of the API. For the e-commerce company during the initial days the delivery load could be very less. The "notify delivery team" part in the API, then, can be implemented by sending email or SMS notification to the delivery team. But, as the company grows, they can think of changing the delivery process by automating the delivery process. In this scenario, the implementation of "notify delivery team" changes form sending email / SMS message to sending notification to the delivery system to initiate delivery process.
This is one of the ways how Flexbase provides an evolving architecture. APIs can be easily extended without breaking the existing code.
Let us now design the API for Confirm Order for COD requirement.
From the requirement, following components of the API can be identified immediately:
- 1.Action type is POST
- 2.Starting point is a user form (user wants to confirm order for COD)
- 3.The command is ConfirmOrderforCOD
The diagram below in FlexStudio covers these components.
You can add the other 3 components which are the validations - IsStockAvailable, IsShoppingAddressValid and IsCODApplicable
This makes 6 components in the API
- 1.Action type is POST
- 2.Starting point is a user form (user wants to confirm order for COD)
- 3.The command is ConfirmOrderforCOD
- 4.The first validation is IsStockAvailable
- 5.The second validation is IsShoppingAddressValid
- 6.The third application is IsCODApplicable
Validations are added in FlexStudio in the right hand-side Plug-in pane.
The next component of API is the first event that will be created in the queue. It is obvious that the first domain event here is Order Confirmation for COD. So the first event created in the queue will be OrderConfirmedforCOD.
Now the API looks as follows,
- 1.Action type is POST
- 2.Starting point is a user form (user wants to confirm order for COD)
- 3.The command is ConfirmOrderforCOD
- 4.The first validation is IsStockAvailable
- 5.The second validation is IsShoppingAddressValid
- 6.The third application is IsCODApplicable
- 7.The domain event is OrderConfirmedforCOD
In FlexStudio it looks like
Note: In FlexStudio you don't need to worry about the implementation of the domain event. It can be database persistence in most of the cases.
If we look at the requirement, there need to be two subscribers listening to this event - notify the delivery team and notify the customer.
These two subscribers in turn can publish their own domain events. This is the premise of pub-sub pattern.
"Notify the delivery team" can publish "Delivery team notified" event. And "notify the customer" can publish "Customer notified" event.
Let's create one subscriber and it's event, at a time.
First you can add the "notify the customer" subscriber. You can call it NotifyCustomerOnCODOrderConfirmation
In FlexStudio it looks as follows,
You can now add the event emerging from this subscriber - CustomerNotifiedOnCODOrderConfirmation
Similarly, you can add another subscriber to the OrderConfirmedforCOD domain event. NotifyDeliveryonCODOrderConfirmation and it's event DeliveryNotifiedonCODOrderConfirmation
As you can see, FlexStudio allows you to add multiple subscribers to an event.
So, in the end the API has following components,
- 1.Action type is POST
- 2.Starting point is a user form (user wants to confirm order for COD)
- 3.The command is ConfirmOrderforCOD
- 4.The first validation is IsStockAvailable
- 5.The second validation is IsShoppingAddressValid
- 6.The third application is IsCODApplicable
- 7.The domain event is OrderConfirmedforCOD
- 8.The first subscriber to the domain event is: NotifyCustomeronCODConfirmation
- 9.The event published by first subscriber is: CustomerNotifiedonCODOrderConfirmation
- 10.The second subscriber to the domain event is: NotifyDeliveryonCODConfirmation
- 11.The event published by the second subscriber is: DeliveryNotifiedonCODOrderConfirmation
In next section, we will show how you can create your first application.
Last modified 3yr ago