Link Search Menu Expand Document (external link)

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)