Skip to content

technical-specifications.md

Latest commit

 

History

History
200 lines (153 loc) · 6.93 KB

technical-specifications.md

File metadata and controls

200 lines (153 loc) · 6.93 KB
Raw

Technical specifications

Technologies

Architecture

Here is the architecture of the project, which respects clean architecture :

.
├── src
│   ├── app
│   │   ├── controllers
│   │   ├── data
│   │   ├── exceptions
│   │   ├── gateways
│   │   │   └── repositories
│   │   ├── ports
│   │   │   └── usecases
│   │   │       ├── player
│   │   │       ├── prepare
│   │   │       ├── proposal
│   │   │       ├── session
│   │   │       ├── state
│   │   │       ├── stats
│   │   │       └── turn
│   │   ├── presenters
│   │   └── usecases
│   │       ├── player
│   │       ├── prepare
│   │       ├── proposal
│   │       ├── session
│   │       ├── state
│   │       ├── stats
│   │       └── turn
│   ├── common
│   │   ├── communication
│   │   ├── decorators
│   │   │   └── func
│   │   ├── dto
│   │   ├── enums
│   │   ├── exceptions
│   │   ├── logs
│   │   └── patterns
│   │       ├── mediator
│   │       └── memento
│   ├── domain
│   │   ├── core
│   │   ├── entities
│   │   └── values
│   │       ├── combinations
│   │       ├── sessions
│   │       ├── stages
│   │       └── turns
│   │           └── indicators
│   ├── infra
│   │   ├── database
│   │   │   └── models
│   │   ├── env
│   │   └── repositories
│   └── ui
│       └── cli
│           ├── components
│           └── handlers
└── tests
    ├── archi
    │   └── patterns
    └── units
        └── domain
            ├── core
            ├── entities
            └── values

app

This folder contains the application part of the clean architecture.

Here's the list of items you can find:

  • Controllers
  • Custom exceptions
  • Gateways
  • Ports
  • Presenters
  • Use cases

common

This folder is the common library for the front-end and back-end.

Here's the list of items you can find:

  • All about design patterns structure
  • All about communication between front and back

domain

This folder covers the domain of clean architecture.

Here's the list of items you can find:

  • Entities
  • Value objects
  • Core objects (responsible for enforcing the rules of the game)

infra

This folder covers the infrastructure part of clean architecture.

Here's the list of items you can find:

  • Repositories
  • All about database configuration
  • All about environment variables

ui

This folder contains all the project's graphical interfaces.

Here's the list of items you can find in each UI :

  • Components
  • Handlers (middleware between CLI and Controllers)

tests

This folder contains all the project tests.

Here's the list of types of tests you can find:

  • Architecture tests (clean architecture, design patterns, etc)
  • Unit tests

Game rules

Game rules are managed mainly by the Rules object but also by entities, value objects and others core objects :

Entities

Value objects

  • Combination : represents combinations of Beads
  • Turn : element of Session
  • Feedback : represents feedbacks returned by the system for a proposal
  • Indicator : element of Feedbacks (represents red and white pawns)

Core objects

  • Arbitrator : evaluates and compare combinations
  • Generator : generates random combinations and beads
  • Rules : handle game rules
  • Storage : manage local storage

Session management

Sessions are managed using a memento pattern. When I save a game, a snapshot (SessionMemento) is created of the state of the game and saves it in a history (SessionHistory). When I need to resume a game, the snapshot is retrieved from the history and restored to the exact state it was in.

User interfaces

Communication

Communication between backend and frontend is managed by a Mediator. Every controller, every manager and every user interface subscribes to it. Handlers act as intermediaries between controllers and user interfaces, and are used in particular for menus. This enables communication with a system for sending and responding to events. When I need to trigger an event from a subscriber, I send a message and all the other subscribers receive it. Each of them then decides whether or not to process it (using the handle function). It's also possible to transmit data using the dtos. This model also allows me to evolve the application: I can add as many handlers, controllers and graphical interfaces as I like.

Data objects are transmitted only between backend controllers, whereas DTOs are transmitted between frontend and backend. Presenters convert Data objects into DTOs, acting as mappers.

CLI

The CLI graphical interface is managed by the CLI object, which uses the Displayer object to display elements on the screen. The Displayer uses components. The CLI will call events using handlers.

Commits convention

To make commits legible and easy to write, I use the Gitmoji convention.