This repository will contain the artefacts produced by the "It Depends" team for the Autumn 2022 session of O'Reilly Architecture Katas. The project this season is to create a proposed architecture for "Hey Blue!", a system to facilitate moments of meaningful connection between police officers and members of their community.
We are minds of software engineers and architects who have come together across three continents to work collaberatively and produce this proposed architecture.
- Shari Lines
- Miguel Gasca
- Kavya Shivakumar
- Prashant Jasani
- Susmita Kunishetty
- Uma Kapoor
To design a feasible mobile/web solution which helps community by enabling citizens and police officers to connect and earn points which can be redeemed in charities or retail store.
The directory linked to contains all artefacts related to functional and non-functional requirements, as well as user story diagrams derived from the 4 processes documented in the original requirements.
- Business Process Workflow : Consists of process workflows for interaction, redeeming and registering.
- System Requirements
- User Cases
- Vision is an abstract diagram illustrating the overall vision of Hey Blue!.
- Evolutionary Considerations takes note of potential directions of evolution of Hey Blue! regarding Usability and scope of positive interactions.
- Volummetric Analysis has some napkin calculations feeding into throughput and scale requirements of Hey Blue!
This is a domain model that fed further into our analysis. We hae used different colors to denote areas of closer conceptual relation. Note: The shapes don't necessarily imply services/actions and the lines don't necessarily imply dependencies/calls/messages/events. This ismeant to be a starting point for decomposition.
- Interactions is larger, red and in the middle because it is the core of the system.
- All Civilian/Officer core domain areas are orange.
- All retail business areas are green.
- All charity areas are blue.
- All data/reporting/analytics is purple.
- Monetary domain concepts in yellow.(i.e. how does HeyBlue make money and how do they apportion part of this to go back to community building).
- Grey is 3rd party and white is cross-cutting.
-
Non Functional Decisions Records This contains all recorded decisions made during our process. Starting with the first one to adopt MADR format and guidelines.
- Design principles
- Architectural Characteristics
- Structural Decisions including Architectural Style ADR
-
Functional Decisions Records
We have identified core architectural characteristics into this worksheet based on Architecture Characteristics Worksheet
We built a worksheet based off of the one found at Developer to Architect Styles Worksheet. We considered all styles listed there except for Layered (it was least well suited from the list and has poor domain to architecture isomorphism). We added to the list Serverless and also a hybrid Event-Based-Serverless. The results of our analysis with a table constrained to our core characteristics is as follows:
(Detailed explaination in 010 Architectural Styles
We have logically seperated our perspective of the architecture into 4 categories.
- Interaction Manager : Responsible to manage Civilian and Citizen registration and their potential interactions with each other by faciliting proximity detection, interfacing with social media and analytics.
- Donation and Redemption : Responsible to manage and administer Business and charities' relations along with point system and redemptions.
- Analytics and Reporting : Responsible for analytics and reporting and operational data management
- Media Manager : Responsible for Social media management
Each of these categories contain the following
- Context Diagram
- Container Diagram
- Sequence Diagram/Data Model
This is how we envisage connecting the dots top down/bottom up architecture
We have maintained templates for
- C4,
- Draw.io Stencils
- MADR3.0 template