3.2. Process First Design

Start system design with Processes

How it works

1. Absolutely any code solves a task, so first we need to figure out "what result we want to achieve," that is, describe the Tasks

2. Next, we describe the Processes – the sequence of actions that we must perform to solve the Task.

3. Then we go through the description of all Processes and can extract Data Structures, dividing them in a way that will respond well to the Processes.

4. The next step is to identify steps that are repeated in Processes and extract them into Operations.

i. Tasks

1. The client should be able to:
1. Search for products
2. Add them to the cart
3. Place an order
4. View order history
5. Change data of an order that hasn't been collected yet
6. Receive notifications about order status changes
7. Register and Authenticate

2. Admin should be able to:
1. Add products
2. See customer orders
3. Change order data
4. Change order status

ii. Processes

1. Client
1. Place an order
1. View the list of products in my cart
1. Input (I): user identifier
2. Output (O): Cart
2. See the sum, discounts, promotions, delivery conditions
1. I: Cart identifier, Delivery Condition identifier
2. O: original amount, discount size, delivery cost, total amount
3. Pay for the order
1. I: Cart identifier
2. O: link to the payment system
4. View the completed order
1. I: Order id
2. O: Order data

2. Admin
1. Add product
1. Add product description
1. I: description
2. O: OK
2. Cost
1. I: number
2. O: OK
3. Delivery features
1. I: set of delivery condition identifiers
2. O: OK
4. Set categories and tags
1. I: set of category and tag identifiers
2. O: OK
5. Add it to promotions
1. I: set of promotion identifiers
2. O: OK
6. Describe which discount policy it belongs to
1. I: set of discount policy identifiers
2. O: OK

iii. Data Structures

1. User – User or Admin
1. id

2. Product
1. id
2. name
3. price

3. Cart
1. id
2. productIds
3. userId

4. Order
1. id
2. productIds
3. userId
4. status
5. addressId
6. deliveryTypeId

5. Receipt
1. id
2. status
3. orderId

6. User Address
1. id
2. city
3. street
4. userId

7. Delivery Conditions
1. id
2. name
3. prices

8. Payment Type
1. id
2. name

9. Promotion
1. id
2. name
3. productIds
4. priceCoefficient

10. Discount Policy
1. id
2. name
3. productIds
4. userIds
5. priceCoefficient

• since we don't have OOP, I don't need to make them according to some principle of combining behavior and data. No, I describe them in a way that will be convenient for me to store them in the database. That is, if it would be convenient to store an Order in pieces in 3 different databases, then I would have 3 different data structures describing how it is stored in these databases.

iv. Operations

1. Change order data – logic that is available to both Admin and User, the only difference being that the admin has access to this change in any Order status, and the User only in the "Formed" status.

// The main difference from the design stage is that we first
// describe Data Structures, then Processes, then Operations


// # Data Structures

// ./data/main-db-data-structures.ts
type User = {
  id: string;
  role: "client" | "admin"
}

type Product = {
  id: string;
  name: string;
  price: number;
}

type Cart = {
  id: string;
  productIds: string[];
  userId: string;
}

type Order = {
  id: string;
  productIds: string[]
  userId: string;
  status: string;
  addressId: string;
  deliveryTypeId: string;
}

type Check = {
  id: string;
  status: string;
  orderId: string;
}

type UserAddress = {
  id: string;
  city: string;
  street: string;
  userId: string;
}

type DeliveryType = {
  id: string;
  name: string;
  prices: number[]
}

type PaymentType = {
  id: string;
  name: string;
}

type Stock = {
  id: string;
  name: string;
  productIds: string[]
  priceCoeficient: number;
}

type DiscountPolicy = {
  id: string;
  name: string;
  productIds: string[]
  userIds: string[]
  priceCoeficient: number;
}


// # Processes, with description of Input and Output Data Structures

// ./process/get-my-cart.ts
const getMyCart = (userId: string): Cart = {
  return db.cart.findOne({ userId: userID })
}

// ./process/calculate-cart-sum.ts
// this type belongs only to the Process below, so it will be described
// next to it
type CalculateCartSumResult = {
  sumPrice: number
  deliveryPrice: number
  totalPrice: number
}

const calculateCartSum = (cartId: string, deliveryTypeId: string): CalculateCartSumResult => {
  const carts = db.cart.findOne({ userId: userID })

  // Get Products
  const products = db.products.find({ id: carts.productIds })

  // Get related promotions and discounts
  const stocks = db.stock.find({ productIds: products.map(p => p.id) })
  const discountPolicies = db.discountPolicy.find({ productIds: products.map(p => p.id) })

  // Get delivery type
  const deliveryType = db.deliveryType.find({id: deliveryTypeId})

  // And here are some cost calculations
  return {
    sumPrice: ...,
    deliveryPrice: ...,
    totalPrice: ...,
  }
}

// ./process/confirm-order-ts
const confirmOrder = (
  cartId: string,
  deliveryTypeId: string,
  paymentTypeId: string
) => {
  // ...
}

// and so on for all Processes
// ...

// # Now let's describe Operations that can be reused by Processes

// ./opertaions/change-order-info.ts
const changeOrderInfo = (order: Order, byWhom: user, newOrerData: Partial<Order>): void => {
  // Prohibit changing order information if it is not in "formed" status and
  // the Client wants to change it
  if (order.status !== "formed" && user.role === "client") return;
  
  // If everything is ok, then we do all the necessary transformations
  // ...
}

1. I don't combine Processes into any "Services" and the like.At most, I might combine them into some module or microservice by domain (for example, in one place, everything related to Cart, Products, and so on; in another, everything related to Promotions; in a third, Payments), which would affect which folders the functions of these Processes would be in.

2. Each Process and Operation can use absolutely any Data

What's next