3.9 KiB
Project Structure
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:
**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.