Potion/doc/ProjectStructure.md
Hayden Hargreaves e8d4d8d8ab (DOCS): Created the Project Structure guide.
This serves as outsider notes as well as my own reference sheet.
2025-06-13 14:59:39 -07:00

102 lines
3.9 KiB
Markdown

# Project Structure
<!--toc:start-->
- [Project Structure](#project-structure)
- [Data Flow](#data-flow)
- [Directory Structure](#directory-structure)
- [Handler](#internalapphanders)
- [Services](#internalappservices)
- [Domain](#internaldomain)
- [Infrastructure](#internalinfrastructuredatabase)
- [Templates](#internaltemplates)
- [Static](#webstatic)
<!--toc:end-->
This document describes how the **Potion project** is build. Where each piece can
be found, and where new pieces should be built.
This project attempts to follow the **Domain Driven Design** (DDD) pattern which
means that the software should be written in a way that represents the business
requirements and domain. The goal is to produce software that is technically
sound but also a strong reflection of the business domain.
DDD implementation in this project means that each "domain" (users, recipes,
etc) are defined in their own domain segment and should be used throughout the
project.
## Data Flow
Data flows through a strict pipe line, as described bellow:
```md
**HTTP > handler > service > repository**
```
The data is first send from the client via **HTTP**. The data is routed to the
proper **handler** which will take control of request and eventually send the
response back to the client.
The handler will then call the proper **service** which will complete any business
logic required before sending the data to the respective **repository.** This
repository (which implemented the proper *domain* interface) will communicate with
the database and perform and database actions, finally returning the new data
back to the service.
Finally, the service will clean up the data and ensure the data fits into the
proper *domain* object and is then bubbled back up to the handler which sends the
response to the client.
## Directory Structure
The directory structure of this project intends to achieve the most efficient
structure while still meeting the goals defined above.
#### `internal/app/handers`
**Handlers** are responsible for receiving requests and sending back responses.
These strongly mimic the controller in the well-known **Model View Controller**
(MVC) architecture. Very little logic takes place here.
#### `internal/app/services`
**Services** are responsible for the majority of the software's business logic. When
a request is received by the handler, the service is called and executes all logic
required to achieve the end response. However, the service has no communication
and therefore relies on the repository for the database.
#### `internal/domain`
The **domain** is the definition of the data models and interfaces that are used by
the application. The data model of each domain object is defined here as well as
the respective service and repository interfaces are defined here. No logic will
be placed here, simply just definitions and interfaces.
#### `internal/infrastructure/database`
The **infrastructure** module is responsible for housing communication to outside
sources, such as the database. The database section (defined here) contains all
**migrations**: SQL definitions of database changes. It also contains all of the
**repository** implementations as defined by the domain interfaces.
#### `internal/templates`
**Templates** are HTML templates which are served to the user as the web UI. This
directory has a very module structure; being broken down into many categories:
- **Layouts:** Page layouts and other large wrappers.
- **Components:** Small scale components for use in various other templates.
- **Partials:** Smallest size elements: common buttons, headers, text elements.
- **Pages:** Individual pages which are composed and served to the user.
#### `web/static`
**Static** documents, elements, or other assets are stored in the web directory.
Items such as images, icons, style sheets, or even JS scripts can be stored here.
This directory will be hosted by the server as a static directory for access by
the UI.