Dancer

Table of Contents

1. Introduction and Goals

From many perspectives we consider partner dance as something really great.

  • You get together with other people.

  • You improve your fine motor skills

  • It is in general a pretty healthy thing

  • The coordination with the music has also positiv impact on your mental health.

  • Great way to find the partner for you life

  • With more people dancing, have mor peace on earth ;-)

But there is something that is kind of barrier for many people to practice dancing!

How can they find a partner?

In this project we want to develop a community that brings together people that wants to practice dancing.

1.1. Requirements Overview

Dancier is aimed to be the goto System for all people looking up dancing related stuff.

This is really kind of a strech goal. So we partitioned the features in two groups.

One that we will really focus on, where we want to make the point. We call them core features.

And the other one additional features.

1.1.1. Core features

  • Enable the User to tell us want kind of dances he can/likes

  • Compute some recommendations for each dancer, want dance partner would match most for him.

Those features are MVP relevant. So they must be included in the MVP:

The following one will be still core, but tackeld after the MVP:

  • Enable Dancers and Event-Creators to provide information about upcoming dancing events, like dance evenings. This events will be presented in the same view, like the recommendations for dancers.
    Those Events could be eg:

    • Dance Evening

    • Workshops

    • Festivals

    • Contests

    • Dancing Holidays

  • Enable Dance-Schools to provided information about themselves. Information for this schools will be included in the recommendation view.

1.1.2. Additional features

When we managed that the core features have been implemented, then we can implement the following:

  • Allow any other dance related content to popup in the recommendation view where appropriate.

  • Improve the Events part:

    • Let the user give information if he joins an event or not.

    • In case he joins:

      • Add him in a temporary chat group only for this event to bring him into contact with others.

    • Enable the users to add groups to chat with others.

1.2. Quality Goals

Nr Quality Explanation

1

Easy to use

Dancer should find easy to use features that are almost self-explanatory.

2

Good recommendations

The recommendations should really fit. In case schools, workshops, shoes and other things where recommended, that should never feel like advertisement but as a good tip.

3

Attractive

Not only the UI should feel someway modern, also the complete project should feel like what we are: a nice group of people with the strong goal to do something useful for the world ;-)

1.3. Stakeholders

Role/Name Contact

Dancer

Should be able to get in touch with other dancers, to dance with them and share information

Schools

Should have a fine channel to get in touch with dancer that need courses, workshops and so on

Shops

Shops for dancing shoes for example connect with dancers

Developer

Learn in a hollistic way how to develop a complete product. In big companies many developers are so heavily specialized, that the lack a holistic view on software development. And sometimes the do not have a fantastic sympathetic team.

2. Architecture Constraints

We are so constrained. Even in multiple dimensions:

2.1. Technical Constraints

Constraint Background/Motivation

Software and programming constraints

TC1

Default Programming Language for Backend development ist Java

This seems to be still a kind a standard language for business backend applications and in the current team, the best understood language

TC2

Default for Data related services is Python

This is the defacto standard for such services

TC3

Default frameworkd for backend development is Spring-Boot

defacto standard in the Java-World

TC4

Default Database is PostgreSQL

kj

TC5

Default Object Store is S3 with Minio

Infrastructure Constraints

TC6

Everything in a Container

TC7

Everything through central IAM

TC8

Loggin to Elastic

TC9

Traefik

2.2. Organizational Constraints

Constraint Background/Motivation

OC1

Founder is Marc

Dancer, that wants a plattform to connect other dancers together. Wants to learn how to drive a product holistically. May earn something, somewhen with it.

OC2

Team

Wants to learn how to drive a product holistically. Have a great time working together. Have a reference project. No intention to earn anything with it.

OC3

Workmode: always pair

Where ever possible, use 4eyes-principle/pair with some other, to achieve mostly to things: share knowledge and grow by this, do not be the one that is not allowed to die

OC3

Workmode: startup

Only do things that immediatly pay of in the next 6 months. Thins that slow us only down and pay off later: do not do this.

OC4

Licence

All the source code will be released under an open source license. Everyone can fork the project and start a dancier on his own (with another name of course)

2.3. Conventions

Convention Reasoning

C1

Be polite

being aggressive, rude.. will never to anythign good when working together

C2

Hear first

Confronted with some point of views that seem strange to you have the respect of your collegue that your first thought ist: he will have his reasons. So give him first a chance to explain and then thing about it.

C3

Code Style

Use the Java Code Style of google. Use PEP8 for python. Aim to follow the principles of clean code.

3. System Scope and Context

3.1. Business Context

Dancier stands on its own, in that way that no technical interfaces to other non dancier systems exist.

All relevant stakeholder will use an web interface to perform their needed work.

3.2. Technical Context

We are not communicating with other non-dancier systems.

4. Solution Strategy

Dancier is composed out of the following components:

high level architecture

We are using the following architectural patterns:

4.1. Bounded Contexts

Each service has kind of its own responsibility. Everything that is considered as strongly cohesive, is bundled together in one system. So when you want to change a certain feature, you rarely will have to change more than one service at the very same time.

This enables one team working eg. on the dancer service, can do it’s work without interfering with the work of the team that works with the recommendation service.

The bounded contexts in this project are:

4.1.1. Show Dancer

A Single Page Application, that is the UI for the stakeholder of the Projekt.

4.1.2. Dancer

Contains the core of the project. Maitains the Dancer Profiles, The Schools and so on.

Acts as a Backend for Frontend for the Single Page Application the Users of Dancier will use, when interacting with Dancier.

The Dancer will emit all Events that are needed by other System, by sending it in a S3 Bucket. This happens asynchronously. In this way, the dancer will not suffer when the downstream systems are temporarily unavailable.

4.1.3. Chat-Dancer

Contains all the functionality that is need to enable den Dancer to chat with one another.

4.1.4. Recommendation

Contains a recommendation engine for everything dancier recommends to it’s users.

Every data that the engine needs, it being read from a S3 Bucket. I will not impose any stress on the leading systems as it would be, when it eg. directly uses there databases.

4.1.5. Other

We also have kind of technical contexts:

  • IAM

  • Monitoring/Logging

4.2. Individual Scalability

Be having different Systems for each different block of functionality, we can also indiviudally scale those systems. Eg. the Chat-Dancer is much more likely that it will be needed that this one have to scale up.

4.3. One Database per Context

We are never sharing a database (in this way we are not considering the S3 Bucket as a database ;-) )

This happens for several reasons:

  • Individual Scaleable

  • Hide your own internal Database Schema

  • Freedom to choose the Database archticture that fit’s most. Eg. for the chat dancer a database could be very interessing, once we will have more traffic.

4.4. Asynchronous Decouple

Write asynchronous to S3, effectivly will lead to a system where the recommendation-service could not impose any load on the dancer.

4.5. Chatting

4.6. Login/Registration

login registration states

4.7. Activity diagramm for login

login activity

4.8. Activity Diagram for Registration

registration activity

4.9. Sequenzdiagramm for the Humancheck

humancheck flow

When the human session is established, all subsequent calls to the backend will have the role 'ROLE_HUMAN' sssigned.

5. Building Block View

5.1. Whitebox Overall System

<Overview Diagram>

Motivation

<text explanation>

Contained Building Blocks

<Description of contained building block (black boxes)>

Important Interfaces

<Description of important interfaces>

5.1.1. <Name black box 1>

<Purpose/Responsibility>

<Interface(s)>

<(Optional) Quality/Performance Characteristics>

<(Optional) Directory/File Location>

<(Optional) Fulfilled Requirements>

<(optional) Open Issues/Problems/Risks>

5.1.2. <Name black box 2>

<black box template>

5.1.3. <Name black box n>

<black box template>

5.1.4. <Name interface 1>

…​

5.1.5. <Name interface m>

5.2. Level 2

5.2.1. White Box <building block 1>

<white box template>

5.2.2. White Box <building block 2>

<white box template>

…​

5.2.3. White Box <building block m>

<white box template>

5.3. Level 3

5.3.1. White Box <_building block x.1_>

<white box template>

5.3.2. White Box <_building block x.2_>

<white box template>

5.3.3. White Box <_building block y.1_>

<white box template>

6. Runtime View

6.1. <Runtime Scenario 1>

  • <insert runtime diagram or textual description of the scenario>

  • <insert description of the notable aspects of the interactions between the building block instances depicted in this diagram.>

6.2. <Runtime Scenario 2>

6.3. …​

6.4. <Runtime Scenario n>

7. Deployment View

7.1. The running application

We are planing to deploy our project in the Hetzner Cloud.

<Overview Diagram>

Motivation

<explanation in text form>

Quality and/or Performance Features

<explanation in text form>

Mapping of Building Blocks to Infrastructure

<description of the mapping>

7.2. Infrastructure Level 2

7.2.1. <Infrastructure Element 1>

<diagram + explanation>

7.2.2. <Infrastructure Element 2>

<diagram + explanation>

…​

7.2.3. <Infrastructure Element n>

<diagram + explanation>

8. Cross-cutting Concepts

8.1. <Concept 1>

<explanation>

8.2. <Concept 2>

<explanation>

…​

8.3. <Concept n>

<explanation>

9. Design Decisions

10. Quality Requirements

10.1. Quality Tree

10.2. Quality Scenarios

11. Risks and Technical Debts

12. Glossary

Term Definition

<Term-1>

<definition-1>

<Term-2>

<definition-2>