When an order is received, it is first sent to the order processing system which checks the order type, quantity and required materials to complete the order. If there are sufficient materials to complete the order then it is sent to the manufacturing floor which is fully-automated by robots. As soon as a new order arrives on the queue, the order is broken down in to jobs and allocated to available robots. Robots update their job status to the order tracking system as they are working. Hence the progress of all manufacturing orders and the estimated order completion time can be checked at all times. A robot may work on multiple jobs at a given time. Robots also monitor themselves and other machines for faults. If a fault is found, it is logged and an alert is generated.

Step 1: Business functions and their connections in the form of an informal diagram

In the analysis of the domain, started from the business described and to define an abstract model, where the main elements, their relationships and interactions are, and we will capture them in a document or blackboard. As the analysis deepens, subdomains can be identified, as well as the primary elements (business center), auxiliary or support elements (which contribute to fulfilling the main objective of the order processing system), possible integrations with external systems.

Figure 1: Domain Analysis inform diagram

From the above diagram assumption and business functions identified are:

• Order: It is the fundamental part of the business, the core, everything else exists to guarantee that this process is developed.
• Robot management: It is a key activity, and is related to the order processing and manufacturing workshop, in charge of ensuring the technical state, the estimation of ordering processing times depending on order type and quantity, and the estimation of load, which is performs from an analysis based on historical order processing data.
• User account management: It is a zure cloud subdomain that contributes to the delivery process, as well as billing, returns and order processing system or service (Familiar, 2015).
• Job update status: It is a process that allows the robot, based on load estimates, to instruct a group of robots to execute the job and get all order in queue to be processed.

2: Define bounded contexts. State all assumptions.

The domain model illustrated in the Figure 1 refers to informal real-life representations, such as order processing, users, order manufacturing, order queuing; but this does not mean that the representation is the same in all parts of the system. In limited contexts, the representation of entities is done according to the domain element, for example, in the case, the domain subsystem or that are responsible for repairing robots, are interested in them: order detection, changing job status, ensuring robots understand order quantity, time to take to manufacture the order, last maintenance date; instead, the order processing subsystem would only be interested in knowing if the motorcycle is available or not. Depending on the context, the entity has a different way of representing itself.

Creating a single model to be used in robot workshop and order processing would be unnecessary as well as complex to maintain and evolve in the face of new business requirements. One of the keys to bounded contexts is being able to represent an entity with only the attributes that are relevant in each context. If the experience apply the concept of bounded contexts can be group taking into account if several functions share a single domain model (Vernon, 2013).

Figure 2: Bounded Contexts

Therefore, functionalities into contexts were grouped according to the business domain they share. However, the contexts are not isolated from each other, they necessarily have to interact, the broken lines delimit the business, and the complete lines show the relationship in which two delimited contexts interact. In this case, the order processing context relies on user accounts to obtain order information from the customer and robot management to schedule order manufacturing by the robots.

The interactions between contexts are based on previously defined contracts; in DDD there are two defined patterns called Open Host Service and Published Language, by extending the idea to microservices, interaction contracts (for http/rest cases) would be based on OpenAPI (Kapferer. & Zimmermann, 2020; Vernon, 2013).

3: Apply tactical DDD patterns to define entities, aggregates, and domain services

State all assumptions

 

Tactical patterns are applied within a single bounded context. In a microservices architecture, entity and aggregate patterns are of particular interest. The first step in applying the patterns was to describe what needs to be done within the bounded context of order delivery assumptions:   

• A customer can request a delivery of a product offered by a company previously registered in the Order Processing System.
• The robot that sends the package to the manufacturing floor identifies the order with the updated job status.
• A robot assigns the new order job status to manufacture the order(s) with time taken to complete the process.
• The robots starts to processing the order collaboratively
• An alert system is triggered in case a robot notices any order processing fault in other robots as well as the order processing system.

Based on the functionalities, the robot identifies the following entities:

• Order request
• Order processing  (check order type, quantity, material required)
• Order Queuing
• Job status update
• Order manufacturing (with estimate completion time)
• Fault Notification
• Order confirmation

The Order, Robot Job status update, Order Account entities are aggregates that have Order processing as their central entity. The Fault Notification and Confirmation entities are child entities of Order Processing and Delivery and QR is child of Package. The estimated queuing and processing time, the location of the order processing, the quantity and dimensions are identified as valuable objects. The Order processing aggregate contains the following properties and references to other aggregates.

Figure 3: Aggregate Structure: Order

They are identified as domain events:

• When the robot is on its way to process the order, Notifications are sent that define the recalculated Position and route, time taken to manufacture the order, any fault encountered.
• When the Order processing or manufacturing entity goes through the different states, it sends events indicating the stage in which it is (pending on queue time taken, order quantity, processing time, on the way, close, delivered).

There is need to add a couple of domain services to the order processing system design: a scheduler, in charge of estimating times and stages; and a supervisor robot, that ensures fault are detected faster with the estimated times in each order processing stage. The application of the tactical patterns leads us to the following result.

 

Figure 4: Result of the application of tactical patterns

Step 4: Identify Microservices

Criteria to define microservices are the non-functional requirements of the system: size, expected growth, desired scalability, availability, technologies, size of the order processing robot. Figure 5 illustrates the microservices after applying the decomposition process. The elements framed in yellow belong to other contexts and do not represent specific microservices, they are subject to an analysis similar to the one carried out, but they will not be addressed in this post for simplification.

 

 

Figure 5: Microservices for the Order processing context

The order processing requests will be queued and the MS Scheduler will take care of organizing the Order processing, the order processing events (the stages) will be sent to a queue that the robots will take them to the Order processing and manufacturing history. The same queue may have other subscribers. The design of the identified microservices can be validated based on the following criteria:

• Microservices must adhere to the single responsibility principle.
• The size of the microservice is small to be managed/developed by a team of few robots and independently (Waseem et al., 2020).
• The services are decoupled and the evolution of one does not affect the other.
• Service-service calls are few, or what is the same, the need to apply distributed transactionality is the minimum possible.

 

References

Familiar, B., 2015. Microservices, IoT, and Azure (pp. 69-93). Berkeley, CA: Apress. New York.

Kapferer, S. and Zimmermann, O., 2020, September. Domain-driven service design. In Symposium and Summer School on Service-Oriented Computing (pp. 189-208). Springer, Cham.          Switzerland.

Waseem, M., Liang, P. and Shahin, M., 2020. A systematic mapping study on microservices architecture in devops. Journal of Systems and Software, 170, p.110798.

Vernon, V., 2013. Implementing domain-driven design. Addison-Wesley. Boston.