This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introduction and Goals

Online store of rocks, using the DeDe application, which is a decentralized application for online purchase of products. The application will simulate the basic functionalities of an online store, where users and clients can buy different types of rocks.

1.1. Requirements Overview

The application will be online and accessible from anywhere in the world. Users will be able to search in the catalog any product available in our shop. The users can order different items and the price will be calculated depending on the place from where the order is made and the products that the client buys. The application will store the information about the users and the products in a database MongoDB. Personal information of the users will be protected with SOLID using pods. The application interfaces will be created with an open source library React and the main language for the application will be TypeScript.

1.2. Quality Goals

Priority Quality Motivation



The user must know that his personal information is protected using our application.



The technology is constantly changing and is essential to keep up to date.



The application functionalities should be efficient for the users.



The application must be adapted for every type of user.

1.3. Stakeholders

Role Expectations


Implementation that shows the knowledges of the lessons

Server admin

Server gestion and solve technical problems and doubts


Application easy to manage with a clear interface and adapted to all levels of software knowledge

2. Architecture Constraints

Table 1. Technical Constraints




Implementation in TypeScript

The application will be implmented with TypeScript


Interface with React

The visual interface will be implemented with React.


Database in MongoDB

The data of the application will be stored in the database MongoDB.

Table 2. Organizational Constraints





The application will be developed between March 2022 and May 2022.



Ignacio Gomez Gasch, Valentin Dumitru, Jorge Torano Herrera, Adrian Estrada Gonzalez



The code and infomation of the whole project will be managed in GitHub in a private repository.

Table 3. Conventions





Documentation with arc32 architecture.



The application follows SOLID statements to protect personal information of the users.



Documentation in english.

3. System Scope and Context

DeDe is an online shopping system where users choose the products they wish to purchase by adding one or more addresses to their User POD. The system is integrated with SOLID, where users manage their PODs and their data is under their control.

The system will only store user’s address, securing other type of personal data from being stored.

3.1. Business Context

Business & Tecnical Context

Entity Input Output


The user interact with the application using a computer or other device.

The user output can be different, depending on the user inputs.

User POD

Each user has a POD, the user introduces data into the POD.

The POD sends the required information to the application.


Recieves processed data

Creates visual and interactive components for the user to see and use.


Recieves requests for processed data

Processed data


Recieves data

Sends data

3.2. Technical Context

The system uses a SOLID architecture, respecting user privacy, making personal information decentralized. For this we use user PODS, making users control their own information

Technology Description


Used as database of the WebApp.


Library to ease the programming of the application.


Used to program.

4. Solution Strategy

4.1. Technology decisions

  • React: React makes it easy for us to program user interfaces using JavaScript.

  • Solid: SOLID gives the user the ability to choose what data they want to provide, and makes it easier for us to access it.

  • BootStrap: Bootstrap makes it easy for us to develop HTML and CSS for the web application

  • MongoDB: MongoDB is a non-relational database which allows us to not have to model all relationships.

4.2. How to achieve key quality objectives

Usability & Efficiently

The structure of the web would be similar to the ones already available on the market, this will provide a more easily to use application to the client. We will do some usability test with different user types during developing stages. All web and services will be optimized with the main aim of making queue waiting times faster.

Privacity & Security

We will ensure that the application is robust against the most common attacks, and we will ensure user privacy so that their data would not be leaked.

5. Building Block View

The building block view shows the static decomposition of the system into building blocks as well as their dependencies. It allows us to understand the system as a whole.

5.1. Whitebox Overall System

Whitebox Overall System Diagram

The Whitebox Overall System diagram is a simple diagram to help understand the system by seeing the big picture. As the site is a shopping site, the ineraction is simple.

Contained Building Blocks
  • DeDe: The name of our site. Decentralized Delivery

  • Client: The potential client of our site.

5.2. Level 1

Level 1 Diagram
Name Responsibility


  Stores the data of the client


  Stores our own data


  Our major stakeholder, uses our site

5.3. Level 2

Level 2 Diagram
Name Responsibility


  Stores the data of the client


  Stores our own data


  Our major stakeholder, uses our site


What the user sees and interacts with, the front end.


The server of the interface, processes the information and deals with the database and the PODs

6. Runtime View

6.1. Add Rock to Shopping Cart

6.2. Log In / Register

Hierarchy of building blocks

The the runtime interactions inside the system to log or register are the following:

  • First the client enters the webpage.

  • Then clicks on login/register, it goes to the log in page.

  • The user is required to allow the the app to collect data from the POD.

  • If allowed, the POD gives the necessary data.

  • We look into our database to see if user exists, if exists brings back his data, if dont we store them.

  • Now the user is logged in and it goes back to the home page.

6.3. Purchase

Hierarchy of building blocks The the runtime interactions inside the system purchase any item in our store are the following:


6.4. Delete Product from Shopping Cart.


6.5. Login


6.6. Register


6.7. View User Orders


6.8. Filter Catalog

Hierarchy of building blocks The the runtime interactions inside the system purchase any item in our store are the following:

  • First the client enters the webpage.

  • Then types the desired words to search for.

  • Clicks search.

  • The api processes the request and answers with the items.

  • The interface updates and shows the client their desired products.


7. Deployment View

7.1. Infrastructure Level 1

Deployment View


By using this structure, you can see an overview of how the application will work in runtime

Quality and/or Performance Features

Despite the fact that issues such as connection speed or performance depend mainly on other aspects such as the internet connection, we have tried our best to create a clean code that achieves the best performance for the user. With this, the intention is to achieve a good experience for the user in the use of the application.

Mapping of Building Blocks to Infrastructure
Node Description


The method with which the user will connect to the application

Ubuntu EC2

The virtual machine in which the application will be deployed


The layer of views that the users will be able to see


The layer of logic with which the application will connect


The address of the user will be obtained from his POD


The provider that stores the database in mongodb

DB MongoDB

The database of the application with which the restapi will interact


The API in which the images of the application’s products are stored

8. Cross-cutting Concepts

8.1. Domain model

Domain Model UML Diagram

The address of the clients will be stored in their pods, being requested by the server to calculate the shipping costs. Once this process is done, the server will send the customer the final costs of their purchase.

8.2. Security and Safety

The app will provide users with a safe and secure environment. To carry this out the application will be developed using technologies such as SOLID taking into account its recommendations for use on issues related to data storage using pods. Another aspect is the use of protocols with the HTPPS for the connection with our application.

8.3. Usability

One of the important aspects of our application is that it can be used easily by any type of user. For this, it will be sought that the application has the least number of technical requirements in its use.

8.4. Accessibility

The color palette used in the application will be chosen taking into account that it is accessible to people with some type of color blindness.

9. Design Decisions

Decision Reason


This type of database is according to the requirements of the application.

Visual Studio Code

It will be the development enviroment used by all members of the group. One of its most favorable points is the possibility of adding a wide variety of extensions that will allow the project to be carried out in a simple way


In this platform the images of the application will be stored, making it not necessary to save them locally

Node Geocoder

By using this library we get the coordinates from the user address stored in your POD


This will be the provider that we will use in the Node Geoder api, to obtain the coordinates of the user’s address

10. Quality Requirements

10.1. Quality Tree

Quality Tree

10.2. Quality Scenarios

ID Quality attribute Scenario Priority User/Dev



The application must be intuitive and easy to use bu most users




The user will have the power to choose the (non-essential) information that the application shows or has




The application should offer a certain security and integrity against attacks




The application code should be easily extensible to add new functionality easily




The application must be optimized to minimize waiting times for services




The application code should be easily testable, to facilitate testing to realiease a robust final product


10.3. Risks and Technical Debts

10.4. At the moment


Trade off

Low knowledge of the use of PODS

We have had little time to learn how this technology works. Invest more time to improve the state of the web.

Time. We are conditioned by a delivery date and other subjects

We must optimize individual and group work as much as possible

It is complicated to test the functionalities of the application

Increased work to design tests that test all the functionalities of the application

10.5. At the beginning


Trade off

The interface is unfriendly to users

We will have to invest time to test and code the flows through the interfaces

The payment data of the purchases can intervene

slower payment transactions because the use of SOLID

An attacker can access and modify the data of our application

More time to choose a robust db for the application

Waiting times for application processes are very long

Increased work to design a code as efficient as possible

11. Glossary

Term Definition


Controlled by several local offices or authorities rather than one single one


Open source Javascript library designed to create user interfaces


Usability is a measure of how well a specific user in a specific context can use a product/design to achieve a defined goal effectively and efficiently


Arc42 is a template for architecture communication and documentation.

Building Block

Package of functionality defined to meet the business needs across an organization.

Whitebox Overall System

An overall view of how the system would interact with other systems or users.

Runtime View

Describes the behavior and interaction of the system’s building blocks as runtime elements


Application Programming Interface, which is a software intermediary that allows two applications to talk to each other.

Solid POD

Specification that lets people store their data securely in decentralized data stores.


MongoDB is an open source NoSQL database management program.


NoSQL is an approach to database design that enables the storage and querying of data outside the traditional structures found in relational databases


Bootstrap is a free and open source front end development framework for the creation of websites and web apps


TypeScript is a programming language developed and maintained by Microsoft

Visual Studio Code

Visual Studio Code is a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux


Cloudinary is an api that transform images and videos to load faster with no visual degradation, automatically generate image and video variants, and deliver high quality responsive experiences to increase conversions.


OpenStreetMap is a collaborative project to create free and editable maps.


Identificator for Usability


Identificator for Privacity


Identificator for Security


Identificator for Modifiability


Identificator for Efficiency


Identificator for Testability

About arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

© We acknowledge that this document uses material from the arc 42 architecture template, Created by Dr. Peter Hruschka & Dr. Gernot Starke.