ldynia / archcolider Goto Github PK

I'm not clear on the need for codes to retrieve meals from the smart fridges.

Do we only need to enter a pin code resulting in the meal becoming available? Or do we first need to choose our meal from the fridge and then also enter the pin code?

I'm wondering about this because:

• If we only need the pin code we would need to make sure the pin code is globally unique.
• If the customer needs both the meal number (the same way we choose a Mars bar at a vending machine) then the pin code only needs to be unique locally.
• If both codes are needed we could secure the system a bit more by giving it a limited number of retries. Though that's out of scope we could design the generation of codes.

Please take care to fix links in the document when you move it or rename it.

In ADR 002 we make a decision for a microkernel that can later be turned into a modular monolith.

_"Based on alternatives in the context of the business needs and a development team we think that micro-kernel approach is the best option for now. At the same time it opens the possibility to migrate to microservices when needed.

Can be converted to highly modularized monolith with characteristics of micro-kernel approach"_

A reader could however argue that the rest of the documentation actually doesn't reflect that decision.

What do we want to do about this? We have sub-systems that reflect part of the system under design. Are we going to leave it or argue for a distributed monolith, or a macro-service approach?

• ADR 003 states:

"This is a fast growing system and time fashioned scaling is essential."

There is no indication of what time fashioned scaling really is. Is this supposed to say something like "just-in-time" scaling? Or something else? (metric-based scaling? as it is mentioned a bit later)

• cool customizable dashboards is a colloquialism. I don't mind them but I'm usually very careful putting them in the project documentation. Especially when recommending for or against a product. Management doesn't usually like for a highly paid architect to base a decision on "coolness". Consider taking the word cool out.

The sentence:

This requires [*the] support of idempotent changes, or aware[*ness] of the most recent state for [*of the] order processing service.

Being idempotent and simultaneously aware of the most recent state would be in conflict with each other. It should always return the same thing according to the concept of idempotence.

Another issue with the text (imho the larger issue) is that the ADR is not clear on why we need at least once delivery or why it then flows from that argument that you would need support of idempotent changes, or aware of the most recent state for order processing service

Please consider the changes needed to make this a bit clearer.

I would like to add this to the agenda for tonight's meeting.

This directly impacts cost calculation and should serve as a review as well.

https://github.com/ldynia/archcolider/blob/master/3.ViewsAndPerspectives/UserScenariosPerspective.md

There should be user's concerns, not just users groups.

Also in the Risk section think about more edge cases for discussion with business

Tableau and DataDog represent significant cost percentages for the entire eco-system. This might warrant another look or it might not considering the trade-off in man-hours needed.

Discuss about the Map providers and Finalize one of them

Hi all

I just completed ADR 003

Cheers!

ADR4: The ADR is incomplete. Currently, there is a mix of new information and information that was copied over.

ADR5: The ADR is incomplete. I'm not sure what's supposed to be in there either.
ADR6: Great stuff. I was just wondering if there is a good resource you have in mind to mitigate the risk. If you do we could add that as a link.

ADR9: The ADR makes a very good case for Event Sourcing. We could possibly guide the developers a bit with some best practices. That's not something for the ADR itself though. Unless we can link to a very good source.

ADR14: Possibly add to the context that the occasional user (who pays cash) is a major factor in this issue. Any pre-paid meals that can still be picked up in an offline scenario don't really contribute to the stale data issue as the payment server must already have done its job.

ADR15 and ADR18: The ADRs seem to overlap. But it may still be in progress.

1. In functional requirements, Scheduling meals was mentioned as a separate point in Core Context. But there was not outline for it as it was part of the ordering system, can we remove it?

https://github.com/ldynia/archcolider/blob/master/1.ProblemBackground/FunctionalRequirements.md

2. The Glossary and Diagrams (miro) speak different language, they are pretty minor
   for example: Glossary says Kiosk Management System , in the diagram we mentioned as Kiosk system

3. Do we need to remove the personal presentations(@VioletTape ) and references in docs folder ?

https://github.com/ldynia/archcolider/blob/master/3.ViewsAndPerspectives/InformationModels.md

Working on proof reading in Concurency

https://github.com/ldynia/archcolider/blob/master/3.ViewsAndPerspectives/Concurrency.md

please review and comment

Please check the colors in my diagrams. I'm colorblind, so it might look horrible or be unreadable.

I did not see a description of any type of data backup mechanism.

Should we consider this? If so, let's add it to the agenda for the next meeting.

I will write about our group.

Working ot proof reading in System approach

1. system approach could use some explanation of what the different line types actually mean. For example, in the first figure, there is an easy assumption to be made that the solid lined boxes are services. Though one could also imagine that the dashed lines are service boundaries.

The document states;" Identified services share common Quality Attributes, so the same set of Tactics can be applied."

At a glance, the reader is likely to assume that this is reflected in the same figure. However, when we look at the figure we see that the broad binding boxes (dashed lines) contain disjoint Quality Attribute sets.

A legend or textual explanation could help here. The reader is not part of the current discussion so inferring the meaning of line types and box types would be difficult for them.

In the second figure, the dashes line means something else. This re-enforces the need for some extra explanation. I would personally even argue that there are two separate meanings of the dashed lined boxes in figure 2. The basis for that argument is that one is a monolith and the other one may not be. As support for the latter argument, I quote Solution Overview: Composition
_"Point of Sale and Front End apps might be a single or two different applications."
"

Check other diagrams for the same concept.

2. It looks like, Modularized services contains 2 versions of the same diagram. I'm guessing we want the second one?