Consider adding a Domain Analysis Map of HeyBlue!

[mgasca]

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

[kapooruma]

Somehow i feel that this style of diagraming is ideal for showing Domain Data modeling .. like star schema perhaps.. or to represent state transition. For Architecture Integration/component diagrams, I'd like to see the relationships .. and i'd like to see structure. I like this attempt Miguel, but maybe i need to train my eyes into understanding this

[mgasca]

Hey @kapooruma thanks for your feedback.

It's not clear from your comment

For Architecture integration/component diagrams

However, I think that you are referring to C4 System Context (which may have integration elements) and C4 Component diagrams. This diagram is not meant to be either of those. Keep in mind that there are many diagrams and other artefacts that are not C4 that we may create and submit. The additional artefacts will help us to build the narrative that tells the full story of the architecture. I have tried to capture here pretty much everything from the requirements, broken down into areas of cohesive responsibility.

I would suggest thinking about this domain diagram in a similar way that @lionking421 mentioned detailing user workflows and how @susmithakunisetty submitted a couple flow diagrams (like this one) showing user journey through the system. That is to say, they are meant to provide sufficient detail to enable us to decompose the system into its constituent parts.

My hope is that this diagram would help us to determine how to decompose into different services/actions/stores/components/etc, and also to help communicate to the judges the process we went through to arrive at the decomposition. In fact it's possible to use Domain Driven Design to decompose to microservices or serverless. This diagram could be the first step of that. Following on would be diagramming Bounded Contexts, identifying Aggregates, and then decomposing to Domain Services, Application Services (these are DDD terms, they don't mean services as in microservices) and Domain Events. If you are interested in seeing documentation of an example of this, you can refer to this series of 3 articles on using DDD to model microservices (it can be used the same with serverless, leaning stronger into the event side of things). Note: I'm not proposing we strictly follow DDD, but we can still borrow some concepts from it.

Regarding data modeling/storage/schemas/etc. we have only touched the surface so far in our group conversations around data. Team members have been talking about considering SQL vs NoSQL, and in my requirements review I have also brought up things like Time Series Database (TSDB) and EventStore. For architectural style we have also primarily discussed microservices, serverless and event based. In microservices each service owns its own data, it can be the same (but not necessarily 1:1 action/function:data) in serverless. I don't think we'll have a single data store, so this most definitely is not a data modeling diagram, other than perhaps showing potential areas of decomposition along the same lines of decomposing potential services/actions.

I'd like to see the relationships .. and i'd like to see structure.

I'm not sure why you think that relationship and structure is not shown in this diagram. Can you elaborate?

The shapes imply functionaly/technical boundaries, which translates into structure. The edges imply relationships that can include direct dependencies, events triggering workflows and application flow. e.g.

• Application Flow - the line between "Civilian Profile" and "Storefront" implies a civilian having logged in and then accessing storefronts to browse for items they'd like to redeem for.
• All 3 in one scenario - the lines between "Civilian Profile"/"Officer Profile" and "Presence/Location" imply that individuals have logged in to their profile and have location tracking enabled, which feeds data to "Presence/Location". The line from "Presence/Location" to "Proximity" illustrates a stream of metadata tagged geo-location events that "Proximity" analyses for potential interactions. If it identifies valid proximity between Civilian and Officer, then it raises a ProximityDetected event (which is likely persisted in the persistent EventStore for future analysis). Interactions handles ProximityDetected events and the line between "Proximity" and "Civilian Profile" indicates that Proximity will notify the Civilian that there is a potential interaction they can engage in. The line between "Civilian Profile" and "Interaction" also then conveys that the Civilian follows through on the potential Interaction and reaches out to an Officer, which is mediated by "Interactions". The line between "Officer Profile" and "Interactions" encapsulates both a notification to the Officer of the interaction request, and also them actioning it by accepting it. At this point the simplest form of an Interaction has been achieved, and "Interaction" raises an InteractionOccurred Event, which is stored in the EventStore for playback and future analytics. The "CivilianProfile"/"OfficerProfile" handle this InteractionOccurred Event and deliver intrinsic rewards to each individual (e.g. banner on phone that says "Congratulations, you've just had a positive interaction wtih xxx!). The "PointsAndRewards" handles this InteractionOccurred Event and credits both individual's profiles with points (shown by the lines between "PointsAndRewards" and the profiles).

[mgasca]

@kapooruma I just saw your new issue named "Systems". It seems to me that most everything you have captured is represented in my diagram above. I've attempted to map what Domain Area your "systems" would fall within below. This excersize has also helped me identify a couple gaps in my diagram, thanks.

System	Domain Area
Onboarding	Profiles and Relations
Terms & Conditions	Profiles and Relations
Data Protection	Profiles and Relations
Push Notification	Notifications
Location Tracker	Presence & Location
Points Management	Points & Rewards/Profiles
Connections Management	Interactions
Referrals	I don't have this captured, what is this?
StoreFront Management	Store Front
B2B Services	3rd Party Integration
Connections Report by Zipcode	Event History/Reporting
Points History/Activity	Event History/Reporting
Fee Calculation	Accounting
Points Redemption	Redemption
EOM batch run	Reporting/Accounting/Community Budgets
Community Gains	Community Budgets
Community Spend Plan	Community Budgets
Charity - Retail Mapping	I'm missing a line between Charity Relations and Store Fronts
HeyBlue Social Media	I'm missing this and other social media in my diagram

[mgasca]

I've created an updated domain diagram with the missing relations/element based on analysing alongside @kapooruma set of systems.