System Architecture

[nasadorian]

As a development team,

We want to to discuss and settle on a system architecture for the Green Light Health application so that we can implement it. This architecture may encompass a front end framework, a data layer (databases, queues) and a compute layer (API and data processors). An example architecture is described below for the sake of discussion.

• Front End

  • A modern, mobile friendly way to lay out user interfaces
  • Could be "React" or any JS framework
  • Support 2 user interface flows (Business Owner & End User)

• Compute Layer (API gateway)

  • An endpoint which the Front End will call into, defining the "algebra" of the application
  • Can be represented with REST or GraphQL depending on the needs and complexity
  • Ideally is not a directly mutative API; in other words it should not directly reach into the database for updates. It should simply pass requests onto a queue for a downstream processor. A queue-oriented approach forces .

• Compute Layer (Upstream processor)

  • Reads the main event queue populated by the API server
  • Performs necessary updates to the data layer (e.g. user signed health agreement, business created)
  • Sources new events which may be processed by downstream processor (e.g. user signed negative declaration)

• Compute Layer (Downstream processor)

  • Reads auxiliary events sourced by the Upstream processor
  • Can perform more complicated operations (e.g. graph computations based on negative declarations, updating business states)

• Data Layer

  • An ACID compliant database with robust query API (such as PostgreSQL)
  • Models the entities described in the Domain Model #23 by way of table schemas and keys

[noweber]

@nasadorian In a similar manner to the domain modeling, I don't agree with this user story being on the backlog. I agree that system design has value, but I don’t agree we need or should attempt to take on this much breadth up front. Instead, I believe we should look at the most urgent problems and focus entirely on those. While, of course, we will try to look ahead, we don’t need to force ourselves to attempt to foresee all paths this software could take. Again, we should design slices of functionality with less breadth such that we can better adapt to stakeholder feedback and keep our output focused on working software.

[noweber]

@nasadorian To clarify, I think these should be tasks underneath multiple user stories rather than a single user story itself.

[nasadorian]

@noweber Yeah, that makes sense. We can pick off individual items from here for the product backlog as they become necessary to build.

[noweber]

@nasadorian @jorgecotillo I gave this more thought and did some reading through the evening and morning. I think this is similar to the environment creation stories, which I was on the fence about (we absolutely need them, but I wasn't sure if they should be user stories themselves). I think the way we need to capture this is to create personas within the development team. There are developers who love and are deeply knowledgeable about infrastructure, developers who love system design, developers who love front-end coding, ones who specialize in efficient best practices, etc. Those passions and strengths being captured by a persona means we need to account for them in every story (as needed, of course). Then, even with the infrastructure story, we would be creating the pieces of our environment we need as we go along. Taking each vertical slice piece by piece for what it is. Additionally, it becomes a never ending process rather than a single upfront effort to ensure our infrastructure and system design are part of the discussion because it is integral to everything we deliver our user. Thoughts?

[noweber]

So, as per Richard's response, what I listed seems to be the right approach for this course aside from the developer persona's. Stakeholders should only be people external to the team.