The FTGO application, which is a Spring Boot application, has a monolithic architecture.
It consists of the (Gradle) modules shown in the following diagram:
The key responsibilities of each module is as follows:
ftgo-application
- contains the Spring Boot main application classftgo-order-service
- the order and delivery management controller and domain serviceftgo-consumer-service
- the consumer management controller and domain serviceftgo-restaurant-service
- the restaurant management controller and domain serviceftgo-courier-service
- the courier management controller and domain serviceftgo-domain
- contains domain classes: Consumer
, Courier
, Order
, Restaurant
ftgo-common
- contains generic value objects, such as Money, and Address.Delivery management is responsible for scheduling of couriers who pick up orders from restaurants and deliver them to consumers.
A delivery is scheduled when the restaurant accepts an Order
and commits to a pickup time.
It’s cancelled when the Order
is cancelled.
The scheduling of each courier is primarily driven by their availability and current location, which is provided by the Courier mobile application, and each Order’s pickup and drop-off locations.
Order management
and Delivery management
Although they are logically separate, Order management
and Delivery management
are intertwined as shown in the following diagram:
Delivery Management
is part of Order Management
, within the ftgo-order-service
module.
It also involves part of Courier Management
within ftgo-courier-service
.
In particular, the following types implement both:
OrderService
- in addition to managing Orders
, it also implements the logic for scheduling deliveriesOrder
entity - a single entity represents both Order
s and Delivery
sOrderState
enum - the lifecycle of the order contains both order and delivery management states.Let’s look at each one.
OrderService
classThe OrderService
class contains delivery management logic:
public class OrderService {
public void accept(long orderId, LocalDateTime readyBy) {
...
scheduleDelivery(order, readyBy);
}
public void scheduleDelivery(Order order, LocalDateTime readyBy) { ... }
public void notePickedUp(long orderId) { ... }
public void noteDelivered(long orderId) { ... }
In particular, the scheduleDelivery()
method implements the bulk of the courier scheduling logic.
Order
entityThe Order
entity represents both Order
s and Delivery
s:
@Entity
@Table(name = "orders")
@Access(AccessType.FIELD)
@DynamicUpdate
public class Order {
@Enumerated(EnumType.STRING)
private OrderState orderState;
@ManyToOne
private Courier assignedCourier;
...
OrderState
The OrderState
enum has values corresponds to both order management and delivery management (e.g. PICKED_UP
, DELIVERED
):
public enum OrderState {
APPROVED,
ACCEPTED, PREPARING, READY_FOR_PICKUP, PICKED_UP, DELIVERED,
CANCELLED,
}
Delivery management
and Courier
sDelivery management
also uses part of the Courier
entity:
@Entity
@Access(AccessType.FIELD)
@DynamicUpdate
public class Courier {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private Boolean available;
@Embedded
private Plan plan;
The other aspects of the Courier
entity are not relevant to Delivery Management
, such as their personal and financial details.
Delivery management
and Restaurant
sDelivery management
also needs to know the address of each Restaurant
since that’s the pickup location for an Order
.
@Entity
@Table(name = "restaurants")
@Access(AccessType.FIELD)
@DynamicUpdate
public class Restaurant {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Embedded
private Address address;
The other aspects of the Restaurant
entity are not relevant to Delivery Management
, such its menu.
Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.
Chris helps clients around the world adopt the microservice architecture through consulting engagements, and training workshops.
Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.
Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.
Learn moreChris offers numerous other resources for learning the microservice architecture.
Want to see an example? Check out Chris Richardson's example applications. See code
Got a specific microservice architecture-related question? For example:
Consider signing up for a two hour, highly focussed, consulting session.
My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!
It covers the key distributed data management patterns including Saga, API Composition, and CQRS.
It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.
The regular price is $395/person but use coupon MECNPWNR to sign up for $120 (valid until May 16th, 2023). There are deeper discounts for buying multiple seats.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.
Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.
Engage Chris to conduct an architectural assessment.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · development · devops · docker · eventuate platform · glossary · hexagonal architecture · implementing commands · implementing queries · inter-service communication · kubernetes · loose coupling · microservice architecture · microservice chassis · microservices adoption · microservicesio updates · multi-architecture docker images · observability · pattern · refactoring to microservices · resilience · sagas · security · service api · service collaboration · service design · service discovery · service granularity · service template · software delivery metrics · success triangle · tacos · team topologies · transaction management · transactional messaging