Skip to content

2020 Autumn runner-up, O'Reilly Software Architecture Kata

Notifications You must be signed in to change notification settings

TheKataLog/Self-Driven-Team

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 

Repository files navigation

Farmacy Food Kata

selfdriventeam's architecture proposal for Farmacy Food

Video Presentation

Slides

The Customer

Farmacy Food

Let Food Be Thy Medicine.

Farmacy Food creates tasty meals around your dietary needs, incorporating ingredients known to have beneficial properties to support your health and well-being.

Our Vision

SelfDrivenTeam sees a scalable, extensible system running on a cloud provider where the system scales itself up and down dynamically based on load and response times.

SelfDrivenTeam's system provides secure, reliable functionality for Farmacy Food's customers, nutritionists, chefs, and delivery personnel so they can focus on their areas of expertise while showcasing Farmacy Food's special sauce, the combination of the fresh, wholesome food, nutritionists, and a proprietary meal recommendation engine to provide customers with fresh tasty, nutriutious, and low cost meals tailored to each customer's individual needs and preferences.

The system initially runs for the Detroit, Michigan area, but as service area and usage grows the system can easily scale out to handle multiple geographic areas and scale up within an area to handle increasing customer/POS density. The system includes all of the components needed to meet all of the current requirements and provides extensibility to add known and opportunistic future enhancements.

Requirements from the customer

Users

Dozens of automated fridges and representative run kiosks, thousands of customers.

Requirements

  1. Must integrate with 3rd party smart fridges to obtain inventory and purchase activity
  2. Smart Fridges Produce item inventory levels and purchases. The smart fridges have a cloud based management system that handles communication with the Smart Fridge so obtaining this data would be through an API.
  3. Must integrate with point of sale system at kiosks
  4. The Kiosk is a sublet space inside another business where we will sell our product but have an employee handle the transactions through a point of sale. The same data should be accessible through the POS systems API’s.
  5. Mobile and Web accessible
  6. Support providing feedback on items of verified purchases and in app surveys
  7. Accept coupons and promotional pricing
  8. Send inventory updates to central kitchen

Long term Goals

  1. Long term would like to allow multiple vendors to offer items through points of sale
  2. Wants to harvest data to provide personalized recommendations based on users health goals, purchase history, and item ratings

Our Solution

High Level Architecture

Broken down into 8 major components in a micro-service based architecture, the system provides a S.O.L.I.D. foundation for the next steps (detailed design and implementation). The following diagrams, Architectural Decision Records, Personas, and intermediate artifacts provide more detail on the benefits of the system and why various trade-offs were made when defining the architecture.

Detailed Architecture

Index Description
A High Level Architecture
B Recommendation Engine
C Customer Domain
D Order Domain
E Billing Domain
F Inventory Domain
G Notification Engine
H API Gateway
I UI Component

Architectural Decision Records

Index Description
ADR_001 Use actor/action approach to identify components
ADR_002 No separate delivery component is needed in the system
ADR_003 Stock monitoring and inventory update mechanism
ADR_004 Use a centralized notification for external communication
ADR_005 Component level authorization rules for access control
ADR_006 Sharding/routing as per location
ADR_007 Using External Identity Provider
ADR_008 Data needs to be anonymized for PII
ADR_009 3rd party health hooks into the customer info
ADR_010 Recommendation engine is a batch system
ADR_011 Using micro-services vs event driven
ADR_012 Use mobile friendly web app
ADR_013 Use REST between Customer, Order and Pricing components
ADR_014 Customer domain design decisions
ADR_015 Order domain design decisions
ADR_016 Billing & Pricing domain design decisions
ADR_017 Use queue to update the inventory and external notification
ADR_018 Notification domain design decisions
ADR_019 Inventory domain design decisions
ADR_020 Hybrid approach for recommendation component

Personas

Name Role
Alice Chef
Barbara Kiosk Worker
Claire Analyst
Edward Delivery Driver
Jennifer Subscription Customer
Mark Nutritionist
Scott Occasional Customer

Intermediate Artifacts