Floorplanner Technology Choices
Table of contents
Introduction
Turn explanation into a process recipe.
Detailed information about Using Technology Radars can be found in our process recipe.
This page keeps track of major decisions that relate to Groundwork technology stack. Here we explore libraries and frameworks that are candidates to adopt in support of various architecture concepts and requirements. Decisions are ordered in reverse chronological order (Newest-first) and have states. They represent a Technology Radar. It has one additional ‘Open’ state, meaning that an investigation, called a Spike, is planned.:
Adopt
Trial
Assess
Hold
Open
Decision Log
Adopt C4 for social experience modeling?
Open
C4 Models: “The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase. It’s a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.”
Adopt C4 Models for our project as well as SED solutions? (housekeeping #10)
Adopt AsyncAPI for Event Storming / CQRS representation?
Assess
AsyncAPI wants to be for Event Driven Architecture what OpenAPI is for REST API’s. It is open effort to create an industry standard. How feasible is support of AsyncAPI to define the results from Event Storming sessions and refinement into CQRS/ES models.
Investigation notes can be found in the AsyncAPI vs Event Storming pad.
Decision was to revisit later. It looks promising but a good mapping is not yet possible, and the ecosystem not yet there.
AsyncAPI adoption? (housekeeping #4)