Requirements

Determine the different ways the system will be used. This includes main functions the system needs to perform and who will use it.

Main functions

• Maintain count of each stock in the warehouse
• Manage orders based on price, quantity and size
  • Prioritise order on low size and high quantity and high price
• Always maintain the stock for the incoming order
  • so that when an order comes, we make sure the item is present
• Storage locations based on size

Users

• Who orders? Customers
• Who ships? Delivery partners
• Who manages the orders? Warehouse managers and employees

Core Objects & Relationships

Based on the requirements and use cases, identify the main objects of the system and analyze how they interact and relate to each other...

Warehouse Class

• Stock Class
  • Storage Class
    • Item(Size, Quantity, Price) Class
• Order class
  • Incoming Order Class
  • Delivery Class
    • Shipment Class
    • Delivered Class

Warehouse Class is the main class where we store our Stock, Order Class

Stock class is the class which handles the database of every item

• Here, the database is the items we currently have at the warehouse
• Inside the Stock class,
  • We have Storage class
  • This storage class is the class which stores the item based on size
• Order Class is the class which mainly the controller class
  • It handles the order that customers want to buy
  • It handles the delivery shipment process of the item

APIs & Class Members

For each class, define the attributes (data) it will hold and the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation. Write your code in the code editor below.

API

• /getItems

• /getOrders

• /getOrders/:orderId

• /getDeliveryReport

• /getDeliveryReport/:deliveryId

Deep Dive

Explain design tradeoffs you considered. Check and explain whether your design adheres to SOLID principles. Explain how your design can handle changes in scale and whether it would be easy to extend with new functionalities. Identify areas for future improvement...

Trade offs: Db is the main controller here

• We are assuming MongoDb as it has O(1) look up time
• Data is consistent throughout as it is only one DB

Limitation:

• When data increases, there is no partitioning
  • We could enable partitioning
• There is concern for availability because of one Db. If the database goes down, then everything goes down

SOLID principles trade offs

• Single Responsibility Principle: Here, the Delivery Class follows Single Responsibily Principle as it has only one task to get order status
• Open/Closed Principle: Db does not follow open/closed principle. In fact most of the class are without open closed principle. They have to be edited from inside and cannot expand without touching the code
• Liskov Substitution Principle: We have no subclass replacing its parent behaviour
• Interface Segregation Principle: We have no extension of inheritance here
• Dependency Inversion principle: No dependency on abstraction or no implementations of it