Farmacy Food Kata
selfdriventeam's architecture proposal for Farmacy Food
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
- Must integrate with 3rd party smart fridges to obtain inventory and purchase activity
- 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.
- Must integrate with point of sale system at kiosks
- 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.
- Mobile and Web accessible
- Support providing feedback on items of verified purchases and in app surveys
- Accept coupons and promotional pricing
- Send inventory updates to central kitchen
Long term Goals
- Long term would like to allow multiple vendors to offer items through points of sale
- Wants to harvest data to provide personalized recommendations based on users health goals, purchase history, and item ratings
Our Solution
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 |