# 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.