itdependsq42022 / hey-blue Goto Github PK

This task is to create the initial structure in the repository to hold Architecture Decision Records (i.e. where the Architecture Decision Log will live), and to submit the first ADR. The first ADR, as is common in projects using ADRs, will simply be the decision to use ADRs along with any details on format/convention and potentially ADL conventions.

This issue is to document our decision around Architectural Style selected for HeyBlue based on Requirements Analysis and also taking into account identified core Architectural Characteristics.

One of the key Architectural Characteristics of HeyBlue is Affordabiility due to small budget being a non-profit. Furthermore, being an avenue for engagement and change, it is suitable to engage said community in the ongoing evolution and development of HeyBlue. For these reasons we think it is wise to open source hey blue itself, and invite engagement by the community

Taking the requirements document and our discussions into account I have put together a draft of a domain model that may feed further into our analysis. I wanted to share it with you all and solicit feedback. Note: Interactions is larger, red and in the middle because it is the core of the system. Elsewhere colour is used to denote areas of closer conceptual relation. 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 and yellow is for monetary domain concepts (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. Note that the shapes don't necessarily imply services/actions and the lines don't necessarily imply dependencies/calls/messages/events (though they could). This is just meant to be a starting point for decomposition.

Do you (dis-)like the idea?
Do you have questions about the diagram?
Do you think anything is missing from the diagram?
Do you have feedback on existing elements? (e.g. naming, not-needed, relation missing, etc)?

All feedback welcome

If people find this valuable I will incorporate feedback into the diagram and then open a PR with the draw.io xml file as well as the exported jpg

Host & Frame external sites ( Operate as a Portal ) vs Build Storefront & Municipality pages

Option1 ( Rakeuten.com Model )
Host the Page in HeyBlue App ( like a Frame )

Pros
Delegation
Minimum Integration, Maintenance & Support
Minimum Handshake required
Gives Flexibility for Storefront & Municipalty to keep their existing Look & Feel
HeyBlue does not have to worry about providing Payment mechanisms for the shopping Cart

Cons
StoreFront Existing UI would have to modify their Product Catalog to reflect Points

Option 2
Create StoreFront/Municipality Pages on behalf of the StoreFronts/Municipality

Pros
HeyBlue has the control to create all the UI's

Cons
Will need to get a constant refresh of the Product Catalog ( with Images/videos ) along with the Inventory
Selling Products is not HeyBlue's Business Model. It is to provide points through Interactions
How do you keep the Inventory of the Product in check.
WIll need to cater to Storefront-specific customization
Not Just the Storefront ... Even the Municipality UI would need to follow the same.

PS : I dont call out Charity here because we dont want to offer anymore than the list of Charities that the members can donate to. There is no Charity Page to show ... Please confirm

This is about whether we should prefer using open source tooling, libraries, applications and systems in our proposed architecture. This came up in discussion because Hey Blue! is a non-profit and does not have a large budget with which to build

This issue is to track documenting the key Architectural Characteristics that we have identified for HeyBlue based on Requirements analysis and initial conversations on appropriate Architectural Styles

Personas:
PO
Civilians
Charities
Retail Stores

UI
Connection UI
Rewards History Lookup

Systems

• Onboarding
  Terms & Conditions

• • Data Protection
    

• • Push Notification
    

• • Location Tracker
    

• Points Management
• Connections Management
• Referrals
• StoreFront Management
• B2B Services
• Connections Report by Zipcode
• Points History/Activity
• Fee Calculation
• Points Redemption
• EOM batch run
• Community Gains
• Community Spend Plan
• Charity - Retail Mapping
• HeyBlue Social Media ( is this an existing system .. Or we responsible to build this as well). If we do, then we need to add to UI

offer these users maximum value to fulfill the intent of logging on the app and turning on their location finder.

Service Dependencies

• Location Tracker

Create Usecases (Pending)

To break down the requirements into categories of FR and NFRs so it is easy to match expectations vs actual. and the missed ones are tallied to be put in "readme.md" in the end. (comments?)

To Create Analytics Sequence Diagrams for the container flows