About the FTGO monolith

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 class
  • ftgo-order-service - the order and delivery management controller and domain service
  • ftgo-consumer-service - the consumer management controller and domain service
  • ftgo-restaurant-service - the restaurant management controller and domain service
  • ftgo-courier-service - the courier management controller and domain service
  • ftgo-domain - contains domain classes: Consumer, Courier, Order, Restaurant
  • ftgo-common - contains generic value objects, such as Money, and Address.

About Delivery Management

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.

Tangled 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 deliveries
  • Order entity - a single entity represents both Orders and Deliverys
  • OrderState enum - the lifecycle of the order contains both order and delivery management states.

Let’s look at each one.

OrderService class

The 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 entity

The Order entity represents both Orders and Deliverys:

@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 Couriers

Delivery 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 Restaurants

Delivery 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.

What’s next



Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

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.

ASK CHRIS

?

Got a question about microservices?

Fill in this form. If I can, I'll write a blog post that answers your question.

NEED HELP?

I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

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 NPXJKULI to sign up for $95 (valid until December 25th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter


BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

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.


Join the microservices google group

Topics

Note: tagging is work-in-process

Cynefin   ·  DDD   ·  GitOps   ·  Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  api gateway   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  automation   ·  beer   ·  books   ·  build vs buy   ·  containers   ·  culture   ·  dark energy and dark matter   ·  decision making   ·  deployment   ·  deployment pipeline   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  fast flow   ·  generative AI   ·  glossary   ·  health   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservices rules   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  pattern language   ·  refactoring   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service blueprint   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  survey   ·  tacos   ·  team topologies   ·  technical debt   ·  testing   ·  transaction management   ·  transactional messaging   ·  wardley mapping

All content


Posts

20 Mar 2024 » A tour of two sagas
21 Dec 2023 » Thoughts about team size
24 Jul 2017 » Revised data patterns