Codemia | Master System Design Interviews Through Active Practice

My Solution for Design a Warehouse Management System with Score: 9/10

by iridescent_luminous693

Requirements

1. Stock Management:

Track and update stock levels for each product.
Alert when stock levels fall below a predefined threshold.
Enable real-time updates of stock levels during incoming and outgoing shipments.
Support queries for current stock levels, product availability, and restocking needs.

2. Order Management:

Allow creation of new orders with product details (e.g., quantity, price).
Modify orders before they are fulfilled.
Cancel unfulfilled orders.
Provide status updates for orders (e.g., pending, in-progress, completed).
Track order history (completed, canceled, pending orders).

3. Shipment Management:

Record incoming shipments, updating stock levels accordingly.
Track and update outgoing shipments, ensuring they correspond to valid orders.
Support partial shipments and track the status of partially fulfilled orders.
Provide shipment tracking details (e.g., delivery status, expected delivery date).

4. Location Optimization:

Automatically assign storage locations based on product type, size, and demand.
Reallocate products to optimize space usage in the warehouse.
Track available capacity and suggest optimal locations for new stock based on warehouse space.

5. Inventory Auditing:

Support periodic physical inventory checks to reconcile discrepancies.
Provide detailed logs and audit trails for inventory transactions (e.g., stock added/removed).
Generate reports on stock levels, adjustments, and discrepancies.

6. Reporting and Analytics:

Generate detailed reports on stock levels, order fulfillment, and shipments.
Provide analytics on inventory turnover, product demand, and storage efficiency.
Generate financial reports related to stock movements, order cost, and shipment expenditures.

7. Risk Management:

Alert users to potential stockouts or overstock situations.
Track and optimize stock levels based on historical data and predictive analysis.

8. User Management:

Handle user authentication and role-based access (e.g., warehouse staff, managers).
Support user permissions for creating, modifying, or canceling orders, managing inventory, and generating reports.

9. Real-Time Notifications:

Notify users of important events such as order status changes, stock level alerts, and shipment status.
Send alerts for low-stock warnings or inventory discrepancies.

Define Core Objects

1. Product

Attributes:
- product_id (Primary Key): Unique identifier for the product.
- name: Name of the product.
- description: Description of the product.
- category: Product category (e.g., electronics, clothing).
- price: Unit price of the product.
- weight: Weight of the product for shipping and storage purposes.
- dimensions: Size or dimensions of the product for storage optimization.
- supplier_id: The supplier providing the product.
Methods:
- getProductDetails(): Fetches detailed information about the product.
- updateProductInfo(): Updates the product’s details (e.g., price, description).

2. Stock

Attributes:
- product_id (Foreign Key): Unique identifier for the product.
- quantity: Current stock level of the product.
- location_id: Location in the warehouse where the product is stored.
- reorder_level: Threshold for when the product needs to be reordered.
- incoming_qty: The quantity of the product expected in future shipments.
Methods:
- updateStockLevel(quantity): Updates the stock level when items are added or removed.
- checkStockLevel(): Checks the current stock level and determines if it meets the reorder level.

3. Order

Attributes:
- order_id (Primary Key): Unique identifier for the order.
- user_id: Identifier of the user who placed the order.
- order_status: Status of the order (e.g., pending, completed, canceled).
- order_items: List of order items (product, quantity).
- total_cost: Total cost of the order.
- shipping_address: Delivery address for the order.
- created_at: Timestamp when the order was placed.
Methods:
- createOrder(): Creates a new order with items and user details.
- modifyOrder(): Allows modification of pending orders.
- cancelOrder(): Cancels unfulfilled orders.
- getOrderStatus(): Returns the current status of the order.

4. Order Item

Attributes:
- order_item_id (Primary Key): Unique identifier for the order item.
- order_id (Foreign Key): The order to which this item belongs.
- product_id (Foreign Key): The product being ordered.
- quantity: Quantity of the product in this order.
- price: Price of the product at the time of the order.
Methods:
- getOrderItemDetails(): Retrieves the details of the order item.
- updateOrderItemQuantity(): Modifies the quantity of an order item.

5. Shipment

Attributes:
- shipment_id (Primary Key): Unique identifier for the shipment.
- order_id (Foreign Key): The order associated with this shipment.
- shipment_status: Current status of the shipment (e.g., shipped, in transit, delivered).
- shipping_address: Address for the shipment delivery.
- estimated_delivery_date: The estimated date of delivery.
Methods:
- createShipment(): Creates a shipment for an order.
- updateShipmentStatus(): Updates the status of the shipment.
- trackShipment(): Tracks the current location and status of the shipment.

6. Location

Attributes:
- location_id (Primary Key): Unique identifier for the storage location in the warehouse.
- location_type: Type of location (e.g., shelf, bin, rack).
- capacity: Maximum capacity of this location.
- current_stock: Current quantity of products stored at this location.
- product_id (Foreign Key): The product stored at this location.
Methods:
- allocateLocation(): Allocates a product to a storage location based on available space.
- reallocateProduct(): Moves a product from one location to another to optimize space.
- getAvailableCapacity(): Checks the available space in the location.

7. User

Attributes:
- user_id (Primary Key): Unique identifier for the user.
- username: Username for the user.
- password_hash: Password hash for user authentication.
- role: The role of the user (e.g., admin, warehouse manager, staff).
- email: User's email address.
- contact_number: User's contact number.
Methods:
- authenticateUser(): Authenticates a user during login.
- updateUserProfile(): Updates user profile information (e.g., password, email).

8. Inventory Audit

Attributes:
- audit_id (Primary Key): Unique identifier for the audit.
- audit_date: The date when the audit is performed.
- discrepancy_count: Number of discrepancies found during the audit.
- products_checked: List of products checked during the audit.
- audit_status: Status of the audit (e.g., pending, completed).
- user_id (Foreign Key): User who performed the audit.
Methods:
- createAudit(): Initiates a new inventory audit.
- reconcileInventory(): Reconciles discrepancies found during the audit.
- generateAuditReport(): Generates a report detailing the audit results.

9. Report

Attributes:
- report_id (Primary Key): Unique identifier for the report.
- report_type: Type of report (e.g., stock levels, order history).
- start_date: The start date of the report period.
- end_date: The end date of the report period.
- generated_at: Timestamp of when the report was generated.
Methods:
- generateStockReport(): Generates a report on stock levels.
- generateOrderReport(): Generates a report on order history.
- generateShipmentReport(): Generates a report on shipments.

10. Notification

Attributes:
- notification_id (Primary Key): Unique identifier for the notification.
- user_id (Foreign Key): The user who will receive the notification.
- message: The content of the notification.
- status: Whether the notification has been read or not.
- timestamp: When the notification was created.
Methods:
- createNotification(): Creates a new notification for the user.
- markAsRead(): Marks the notification as read by the user.
- sendNotification(): Sends a notification to the user.

Analyze Relationships

1. Product ↔ Stock:

Relationship: One-to-Many (1:N)
Description: A single Product can have multiple Stock entries. For example, a single product may be stored in different locations across the warehouse. The Stock entity tracks the quantity of the product at different locations.
Interaction: Stock manages the inventory of a Product, and the system can track quantities at different storage locations.

2. Order ↔ OrderItem:

Relationship: One-to-Many (1:N)
Description: A single Order can contain multiple OrderItems. An OrderItem represents a specific product and its quantity in the order.
Interaction: When an Order is created, the corresponding OrderItems are created to reflect the products being purchased. Each OrderItem refers to a specific Product and contains the quantity for that product.

3. OrderItem ↔ Product:

Relationship: Many-to-One (N:1)
Description: Each OrderItem refers to exactly one Product. Multiple OrderItems can point to the same Product (if the same product is ordered in different quantities).
Interaction: OrderItems reference the Product they are related to, and the Product contains details about the item (name, price, category, etc.).

4. Shipment ↔ Order:

Relationship: One-to-One (1:1)
Description: A single Shipment corresponds to a specific Order. Once an order is confirmed and ready for delivery, a Shipment is created to manage the delivery of that order.
Interaction: The Shipment entity tracks the shipment status (e.g., dispatched, in transit, delivered) and is linked to the Order to represent the fulfillment of the order.

5. Location ↔ Stock:

Relationship: One-to-Many (1:N)
Description: A single Location can store multiple Stock entries. Each Stock item in the warehouse is linked to a specific Location where it is stored.
Interaction: The Stock entity is allocated to specific Locations in the warehouse, which helps manage the physical space and optimize storage.

6. User ↔ Order:

Relationship: One-to-Many (1:N)
Description: A User can place multiple Orders. Each Order is associated with a user who created it (e.g., a customer placing an order).
Interaction: The Order entity is linked to a User to track which user placed the order. This is useful for user-specific tracking and reporting.

7. InventoryAudit ↔ User:

Relationship: Many-to-One (N:1)
Description: A single User can perform multiple InventoryAudits. The InventoryAudit tracks discrepancies in stock and is linked to the User who performed the audit.
Interaction: InventoryAudit is conducted by a User (likely a warehouse manager or auditor). The Audit logs any discrepancies in stock, providing insights into stock accuracy.

8. Report ↔ Order:

Relationship: One-to-Many (1:N)
Description: A Report may aggregate data related to multiple Orders over a given time period. For example, generating an Order Report for a certain period that includes details of all orders placed during that time.
Interaction: Reports aggregate and summarize data from the Order and related entities to produce business insights (e.g., total sales, number of orders, etc.).

9. Report ↔ Shipment:

Relationship: One-to-Many (1:N)
Description: A Report can aggregate data related to multiple Shipments. For instance, a report that shows the status of all shipments over a given period, including dispatched, in-transit, and delivered shipments.
Interaction: The Report aggregates data from Shipments, providing insights on shipping performance, order fulfillment, and delivery times.

10. Notification ↔ User:

Relationship: Many-to-One (N:1)
Description: A User can receive multiple Notifications. Notifications are used to inform users about events like order updates, stock alerts, or shipment tracking.
Interaction: The Notification entity is sent to a specific User, and the user may have many notifications related to orders, shipments, or system alerts.

Establish Hierarchy

1. Entity Inheritance Tree:

a. Product, OrderItem, and Shipment (Common Attributes and Behaviors):

The Product, OrderItem, and Shipment classes share certain behaviors like getDetails() or updateDetails(). We can create a base class called InventoryItem which holds common attributes such as id, name, and quantity (for Product) and relevant behaviors. Other classes can extend this base class.

InventoryItem: The base class contains common attributes like id and name, along with methods for fetching and updating the item’s details.
Product: Inherits from InventoryItem and adds product-specific attributes like description, category, and price.
OrderItem: Inherits from InventoryItem and adds order-specific attributes like quantity and price.
Shipment: Inherits from InventoryItem and adds shipment-specific attributes like shipment_date and status.

By inheriting from the InventoryItem class, all three child classes Product, OrderItem, and Shipment can reuse the common logic for handling details, updating, and fetching item-specific information.

b. User and Role-based Permissions (User Management):

The User class has attributes like username, password_hash, and methods related to user authentication. However, users may have different roles (e.g., Admin, Manager, WarehouseStaff). We can use an inheritance structure for role-based permissions.

User: The base class contains common attributes and behaviors (e.g., username, password_hash, authentication).
Admin: Inherits from User and adds administrative behaviors like managing users and generating reports.
Manager: Inherits from User and adds managerial behaviors like approving orders and tracking shipments.
WarehouseStaff: Inherits from User and adds warehouse-specific behaviors like updating stock levels and processing orders.

By using inheritance here, we can easily extend the User class to add specific roles with distinct behaviors while still utilizing the common authentication and profile management functionality.

2. Inventory and Shipment Management (Warehouse Operations):

In warehouse operations, we often deal with inventory (tracking items and stock levels) and shipments (moving items in and out of the warehouse). A base class can be created to manage general operations, which can be specialized by child classes to handle specific operations like incoming and outgoing shipments.

WarehouseOperation: The base class for managing generic warehouse operations, with methods like executeOperation() and cancelOperation().
IncomingShipment: Inherits from WarehouseOperation and adds functionality specific to incoming shipments, such as processIncoming().
OutgoingShipment: Inherits from WarehouseOperation and adds functionality specific to outgoing shipments, such as processOutgoing().

This approach reduces code duplication by consolidating common operations (e.g., status, operation_date, etc.) into a parent class while allowing for specific logic in the child classes related to incoming and outgoing shipments.

3. Reporting and Analytics (Generics for Reports):

Reports in the system might include stock reports, order reports, and shipment reports. All reports have common functionalities like generating a report, adding filters, and exporting data. These can be abstracted into a base class for reports.

Report: The base class for all reports, containing common methods like generateReport(), addFilters(), and exportReport().
StockReport: Inherits from Report and adds functionality specific to generating stock-related reports.
OrderReport: Inherits from Report and adds functionality specific to generating order-related reports.
ShipmentReport: Inherits from Report and adds functionality specific to generating shipment-related reports.

This design allows for code reuse by defining common reporting methods in the Report class, which can be extended for different report types.

4. Notification System (Polymorphism for Notification Types):

To handle various notification types (e.g., email, SMS, in-app notifications), we can use polymorphism with a base notification class and extend it for specific types of notifications.

Notification: The base class for all notification types, with a common method sendNotification().
EmailNotification: Inherits from Notification and implements specific logic for sending an email notification.
SMSNotification: Inherits from Notification and implements specific logic for sending an SMS notification.
AppNotification: Inherits from Notification and implements specific logic for sending in-app notifications.

This structure allows you to easily extend the Notification class with new types of notifications while reusing the common notification sending logic.

Design Patterns

1. Singleton Pattern

Purpose: Ensure that a class has only one instance and provide a global point of access.

Classes: LoggingService

public class LoggingService {
    private static volatile LoggingService instance;

    private LoggingService() {
        // Private constructor to prevent instantiation
    }

    public static LoggingService getInstance() {
        if (instance == null) {
            synchronized (LoggingService.class) {
                if (instance == null) {
                    instance = new LoggingService();
                }
            }
        }
        return instance;
    }

    public synchronized void log(String message) {
        System.out.println(message);  // Simplified logging for the example
    }
}

Explanation:

LoggingService uses the Singleton pattern to ensure only one instance of the logger is created throughout the system.
Double-Checked Locking with synchronized ensures that the instance is lazily initialized and thread-safe.

2. Factory Pattern

Purpose: Provide a way to create objects without specifying the exact class of object that will be created.

Classes: ReportFactory, Report, StockReport, OrderReport

public interface Report {
    void generate();
}

public class StockReport implements Report {
    @Override
    public void generate() {
        System.out.println("Generating Stock Report...");
    }
}

public class OrderReport implements Report {
    @Override
    public void generate() {
        System.out.println("Generating Order Report...");
    }
}

public class ReportFactory {
    public synchronized Report createReport(String reportType) {
        switch (reportType) {
            case "stock":
                return new StockReport();
            case "order":
                return new OrderReport();
            default:
                throw new IllegalArgumentException("Invalid report type");
        }
    }
}

Explanation:

ReportFactory creates objects of type Report based on the input type (stock or order).
The Factory Pattern centralizes the logic for creating objects, making it easier to manage changes when adding new report types.

3. Observer Pattern

Purpose: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Classes: OrderService, Observer, User

import java.util.ArrayList;
import java.util.List;

public interface Observer {
    void update(String message);
}

public class User implements Observer {
    private String username;

    public User(String username) {
        this.username = username;
    }

    @Override
    public void update(String message) {
        System.out.println(username + " received update: " + message);
    }
}

public class OrderService {
    private List<Observer> observers = new ArrayList<>();

    public void addObserver(Observer observer) {
        observers.add(observer);
    }

    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }

    public void notifyObservers(String message) {
        for (Observer observer : observers) {
            observer.update(message);
        }
    }

    public synchronized void changeOrderStatus(String status) {
        notifyObservers("Order status changed to: " + status);
    }
}

Explanation:

OrderService is the subject that changes state, while User is the observer.
The Observer Pattern allows multiple users to subscribe to order status updates, and all observers are notified when the order status changes.

4. Strategy Pattern

Purpose: Define a family of algorithms, encapsulate each one, and make them interchangeable. The strategy lets the algorithm vary independently from the clients that use it.

Classes: ShippingStrategy, StandardShipping, ExpressShipping, Shipment

public interface ShippingStrategy {
    void ship();
}

public class StandardShipping implements ShippingStrategy {
    @Override
    public void ship() {
        System.out.println("Shipping via standard delivery.");
    }
}

public class ExpressShipping implements ShippingStrategy {
    @Override
    public void ship() {
        System.out.println("Shipping via express delivery.");
    }
}

public class Shipment {
    private ShippingStrategy shippingStrategy;

    public Shipment(ShippingStrategy shippingStrategy) {
        this.shippingStrategy = shippingStrategy;
    }

    public synchronized void executeShipping() {
        shippingStrategy.ship();
    }

    public synchronized void setShippingStrategy(ShippingStrategy shippingStrategy) {
        this.shippingStrategy = shippingStrategy;
    }
}

Explanation:

ShippingStrategy is the strategy interface, and StandardShipping and ExpressShipping are concrete implementations of the strategy.
The Strategy Pattern allows dynamic changes to the shipping method at runtime, and the Shipment class uses the strategy to ship products.

5. Command Pattern

Purpose: Encapsulate a request as an object, thereby allowing users to parameterize clients with different requests, queue or log requests, and support undoable operations.

Classes: OrderService, Command, PlaceOrderCommand

public interface Command {
    void execute();
}

public class PlaceOrderCommand implements Command {
    private OrderService orderService;
    private Order order;

    public PlaceOrderCommand(OrderService orderService, Order order) {
        this.orderService = orderService;
        this.order = order;
    }

    @Override
    public void execute() {
        synchronized (orderService) {
            orderService.placeOrder(order);
        }
    }
}

public class OrderService {
    public void placeOrder(Order order) {
        System.out.println("Placing order: " + order.getOrderId());
    }

    public void processCommand(Command command) {
        command.execute();
    }
}

Explanation:

Command Pattern encapsulates an order action (PlaceOrderCommand) and allows it to be executed via a command object.
Command Pattern helps in decoupling the client that sends the request from the object that handles the request.

6. Decorator Pattern

Purpose: Attach additional responsibilities to an object dynamically. The Decorator Pattern provides an alternative to subclassing for extending functionality.

Classes: Order, PriorityShippingDecorator, BasicOrder

public interface Order {
    double calculatePrice();
}

public class BasicOrder implements Order {
    @Override
    public double calculatePrice() {
        return 100.0;  // Basic price of an order
    }
}

public class PriorityShippingDecorator implements Order {
    private Order order;

    public PriorityShippingDecorator(Order order) {
        this.order = order;
    }

    @Override
    public synchronized double calculatePrice() {
        return order.calculatePrice() + 20.0;  // Adds cost of priority shipping
    }
}

Explanation:

PriorityShippingDecorator adds extra behavior (priority shipping) to the Order class without modifying the base class.
The Decorator Pattern allows the addition of responsibilities to an object at runtime.

7. Composite Pattern (Optional)

Purpose: Compose objects into tree-like structures to represent part-whole hierarchies. This pattern is useful when dealing with complex objects, like managing categories and products in a warehouse.

Classes: Category, Product, WarehouseComponent

public interface WarehouseComponent {
    void display();
}

public class Product implements WarehouseComponent {
    private String name;

    public Product(String name) {
        this.name = name;
    }

    @Override
    public void display() {
        System.out.println("Product: " + name);
    }
}

public class Category implements WarehouseComponent {
    private String name;
    private List<WarehouseComponent> components = new ArrayList<>();

    public Category(String name) {
        this.name = name;
    }

    public void addComponent(WarehouseComponent component) {
        components.add(component);
    }

    @Override
    public void display() {
        System.out.println("Category: " + name);
        for (WarehouseComponent component : components) {
            component.display();
        }
    }
}

Explanation:

The Composite Pattern allows you to treat individual objects (Product) and compositions of objects (Category) uniformly.
You can use it to represent categories of products in a warehouse or complex hierarchical structures.

Define Class Members (write code)

1. Product

Attributes:

product_id: Unique identifier for the product.
name: Name of the product.
description: Detailed description of the product.
category: Category under which the product is classified (e.g., electronics, clothing).
price: Price of a single unit of the product.
weight: Weight of the product.
dimensions: Dimensions of the product (for storage optimization).
supplier_id: The supplier's ID supplying the product.

Methods:

getProductDetails(): Returns the details of the product (name, description, price, category).
updateProductInfo(String newName, String newDescription, double newPrice): Updates product details such as name, description, and price.
getStockLevel(): Returns the stock level of the product (it may fetch data from the Stock class).

public class Product {
    private int product_id;
    private String name;
    private String description;
    private String category;
    private double price;
    private double weight;
    private String dimensions;
    private int supplier_id;

    public Product(int product_id, String name, String description, String category, double price, double weight, String dimensions, int supplier_id) {
        this.product_id = product_id;
        this.name = name;
        this.description = description;
        this.category = category;
        this.price = price;
        this.weight = weight;
        this.dimensions = dimensions;
        this.supplier_id = supplier_id;
    }

    public void getProductDetails() {
        System.out.println("Product Name: " + name);
        System.out.println("Description: " + description);
        System.out.println("Category: " + category);
        System.out.println("Price: $" + price);
    }

    public void updateProductInfo(String newName, String newDescription, double newPrice) {
        this.name = newName;
        this.description = newDescription;
        this.price = newPrice;
    }
}

2. Stock

Attributes:

product_id: Unique identifier of the product.
quantity: Current quantity of the product in stock.
location_id: The warehouse location where the product is stored.
reorder_level: Threshold below which the stock should be reordered.
incoming_qty: Quantity expected from incoming shipments.

Methods:

updateStockLevel(int quantity): Adds or removes stock from the warehouse.
checkReorderLevel(): Checks if stock is below the reorder level.
addStock(int quantity): Increases the stock of a product.
removeStock(int quantity): Decreases the stock of a product.

public class Stock {
    private int product_id;
    private int quantity;
    private int location_id;
    private int reorder_level;
    private int incoming_qty;

    public Stock(int product_id, int quantity, int location_id, int reorder_level) {
        this.product_id = product_id;
        this.quantity = quantity;
        this.location_id = location_id;
        this.reorder_level = reorder_level;
        this.incoming_qty = 0;
    }

    public void updateStockLevel(int delta) {
        this.quantity += delta;
    }

    public boolean checkReorderLevel() {
        return this.quantity <= this.reorder_level;
    }

    public void addStock(int quantity) {
        this.quantity += quantity;
    }

    public void removeStock(int quantity) {
        if (quantity <= this.quantity) {
            this.quantity -= quantity;
        } else {
            System.out.println("Not enough stock to remove");
        }
    }
}

3. Order

Attributes:

order_id: Unique identifier for the order.
user_id: ID of the user who placed the order.
order_status: The current status of the order (e.g., pending, shipped).
order_items: A list of OrderItem objects associated with the order.
total_cost: Total cost of the order.
shipping_address: Address to which the order is to be shipped.

Methods:

createOrder(List<OrderItem> orderItems): Creates a new order with the given order items.
modifyOrder(List<OrderItem> newOrderItems): Modifies the order by adding/removing items.
cancelOrder(): Cancels the order if it hasn't been fulfilled.
getOrderStatus(): Returns the current status of the order.

import java.util.List;

public class Order {
    private int order_id;
    private int user_id;
    private String order_status;
    private List<OrderItem> order_items;
    private double total_cost;
    private String shipping_address;

    public Order(int order_id, int user_id, List<OrderItem> order_items, double total_cost, String shipping_address) {
        this.order_id = order_id;
        this.user_id = user_id;
        this.order_items = order_items;
        this.total_cost = total_cost;
        this.shipping_address = shipping_address;
        this.order_status = "Pending";
    }

    public void createOrder(List<OrderItem> orderItems) {
        this.order_items = orderItems;
        calculateTotalCost();
    }

    public void modifyOrder(List<OrderItem> newOrderItems) {
        this.order_items = newOrderItems;
        calculateTotalCost();
    }

    public void cancelOrder() {
        this.order_status = "Cancelled";
    }

    public String getOrderStatus() {
        return this.order_status;
    }

    private void calculateTotalCost() {
        this.total_cost = order_items.stream().mapToDouble(OrderItem::getItemTotal).sum();
    }
}

4. OrderItem

Attributes:

order_item_id: Unique identifier for the order item.
order_id: The order to which this item belongs.
product_id: The product being ordered.
quantity: Quantity of the product ordered.
price: Price of the product at the time of the order.

Methods:

getItemTotal(): Returns the total cost of the order item (price * quantity).
updateQuantity(int newQuantity): Updates the quantity of the order item.

public class OrderItem {
    private int order_item_id;
    private int order_id;
    private int product_id;
    private int quantity;
    private double price;

    public OrderItem(int order_item_id, int order_id, int product_id, int quantity, double price) {
        this.order_item_id = order_item_id;
        this.order_id = order_id;
        this.product_id = product_id;
        this.quantity = quantity;
        this.price = price;
    }

    public double getItemTotal() {
        return this.quantity * this.price;
    }

    public void updateQuantity(int newQuantity) {
        this.quantity = newQuantity;
    }
}

5. Shipment

Attributes:

shipment_id: Unique identifier for the shipment.
order_id: The order that is being shipped.
shipment_status: Status of the shipment (e.g., dispatched, in transit, delivered).
shipping_address: Address for delivery.
estimated_delivery_date: Estimated delivery date for the shipment.

Methods:

createShipment(): Creates a shipment for the order.
updateShipmentStatus(String newStatus): Updates the status of the shipment.
trackShipment(): Returns the current status of the shipment.

public class Shipment {
    private int shipment_id;
    private int order_id;
    private String shipment_status;
    private String shipping_address;
    private String estimated_delivery_date;

    public Shipment(int shipment_id, int order_id, String shipping_address) {
        this.shipment_id = shipment_id;
        this.order_id = order_id;
        this.shipping_address = shipping_address;
        this.shipment_status = "Pending";
    }

    public void createShipment() {
        this.shipment_status = "Dispatched";
        this.estimated_delivery_date = "2022-12-30";  // Simplified for the example
    }

    public void updateShipmentStatus(String newStatus) {
        this.shipment_status = newStatus;
    }

    public String trackShipment() {
        return "Shipment Status: " + this.shipment_status + ", Estimated Delivery Date: " + this.estimated_delivery_date;
    }
}

6. Location

Attributes:

location_id: Unique identifier for the storage location.
location_type: Type of location (e.g., shelf, bin, rack).
capacity: Maximum capacity of the location.
current_stock: The current quantity of products in the location.

Methods:

allocateLocation(int productId, int quantity): Allocates a specific quantity of a product to this location.
reallocateProduct(int productId, int newLocationId): Moves a product to a new location.

public class Location {
    private int location_id;
    private String location_type;
    private int capacity;
    private int current_stock;

    public Location(int location_id, String location_type, int capacity) {
        this.location_id = location_id;
        this.location_type = location_type;
        this.capacity = capacity;
        this.current_stock = 0;
    }

    public void allocateLocation(int productId, int quantity) {
        if (quantity <= (capacity - current_stock)) {
            current_stock += quantity;
            System.out.println("Allocated " + quantity + " units of product " + productId + " to location " + location_id);
        } else {
            System.out.println("Not enough space for this product.");
        }
    }

    public void reallocateProduct(int productId, int newLocationId) {
        System.out.println("Product " + productId + " has been moved to location " + newLocationId);
    }
}

Adhere to SOLID Guidelines

1. Single Responsibility Principle (SRP)

Definition: A class should have one, and only one, reason to change, meaning that it should have only one job or responsibility.
Application in Design:
- Each class in the system has a single responsibility. For example:
  - The Product class is responsible for managing product details like name, description, and price.
  - The Stock class only manages stock levels for products.
  - The Order class focuses on managing the order’s lifecycle, such as order creation, modification, and cancellation.
- The system adheres to SRP because the classes don't overlap responsibilities. Each class manages its domain and leaves other concerns to the respective classes.

2. Open/Closed Principle (OCP)

Definition: A class should be open for extension but closed for modification. This means that the functionality of a class can be extended without modifying its source code.
Application in Design:
- The Factory Pattern used in the ReportFactory class allows for new report types (e.g., new report classes) to be added without modifying the existing factory code.
- The Strategy Pattern used for shipping strategies (like StandardShipping and ExpressShipping) allows for adding new shipping methods without changing the existing code.
- The Order and Product classes are open for extension (you can add new features or behaviors), but closed for modification, as new types of behaviors (like special pricing or promotions) can be added through decorators or new subclasses.

3. Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types without affecting the correctness of the program.
Application in Design:
- The design adheres to LSP because any subclass of a parent class can be used in place of the parent class without altering the desired behavior of the system. For example:
  - The OrderItem class extends Product to represent order-specific product details. The Order can use the OrderItem objects seamlessly as they are substituted for the parent Product type.
  - The ShippingStrategy interface is used by different types of shipping strategies like StandardShipping and ExpressShipping. They can be substituted with each other without any issues in behavior.

4. Interface Segregation Principle (ISP)

Definition: Clients should not be forced to depend on interfaces they do not use. Instead, create smaller, more specific interfaces rather than large, general-purpose ones.
Application in Design:
- The Observer Pattern adheres to ISP by defining a small and specific interface Observer with a single method update(). This ensures that only classes needing to observe changes implement this interface.
- Similarly, the ShippingStrategy interface is small and focused only on shipping-related methods like ship(), ensuring that the implementing classes only need to handle shipping concerns.
- By separating concerns into interfaces, clients (such as OrderService, ShippingStrategy, User) are not forced to implement methods they don't use, adhering to ISP.

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces or abstract classes). Furthermore, abstractions should not depend on details. Details should depend on abstractions.
Application in Design:
- The design follows DIP by depending on abstractions such as the ShippingStrategy interface and the Observer interface rather than concrete classes like StandardShipping or OrderService.
- For example, OrderService uses the Observer interface to notify subscribers, without being dependent on specific observer implementations. This decouples the order processing logic from the notification mechanism.
- The ReportFactory depends on the Report interface, not on specific report implementations like StockReport or OrderReport, which allows easy extension of the report types without altering the factory class.

Create/Explain your diagram(s)

User Requests to Create Order: The User initiates the order creation process, providing product details.

Product Availability Check: The OrderService requests the Product class to check if the product is available for the given order details.

Stock Availability Check: After confirming the product's availability, OrderService checks with the Stock to ensure that there is sufficient stock to fulfill the order.

Order Creation: Once the stock is confirmed, OrderService creates an Order object and corresponding OrderItems.

Payment Processing: The OrderService sends the payment request to the PaymentService to process the payment for the order.

Payment Confirmation: PaymentService confirms the successful processing of payment.

Stock Update: The OrderService then updates the stock levels in the Stock class to reflect the products that have been sold.

Shipment Creation: After updating the stock, the OrderService triggers Shipment creation to prepare the order for delivery.

Order Confirmation: Finally, OrderService sends the order confirmation along with the shipment details to the User.

Future improvements

Concurrency Handling: The use of synchronized methods for thread safety may cause performance bottlenecks under high concurrency. Optimistic locking and thread pooling (using ExecutorService) could improve scalability and concurrency handling.

Database Performance: The use of a single database for all data types could lead to slow queries as the dataset grows. Sharding and read replicas for partitioning data and handling read-heavy queries would improve performance.

Error Handling: The design lacks a robust error handling strategy. Implementing distributed transactions or two-phase commits along with circuit breakers for failure scenarios will ensure reliability.

Monitoring and Logging: The system lacks centralized logging and real-time monitoring. Adding distributed tracing (e.g., with Zipkin) and Prometheus for performance tracking can help with debugging and system health monitoring.

Cache Invalidation: Stale data might be an issue with caching. Implementing cache invalidation strategies (e.g., event-driven or time-based expiration) would ensure the cache is up-to-date.

Advanced Search: Basic search for products and orders may not scale well. Integrating Elasticsearch would support efficient, advanced search queries with better filtering capabilities.

Predictive Stock Management: The system does not currently use machine learning for predictive inventory management. Introducing predictive analytics can optimize stock levels and reorder points.