143 lines
6.8 KiB
Markdown
143 lines
6.8 KiB
Markdown
Okay, ich schlage dir eine detaillierte Projektstruktur für ein Time Tracking and Management System vor, das in Go (Backend) und Next.js (Frontend) mit FPGO und FPTS umgesetzt wird. Das System soll Multi-Tenant-fähig sein, PostgreSQL als Datenbank verwenden und modular, übersichtlich sowie für die Entwicklung mit LLMs geeignet sein. Die Struktur ist in zwei Hauptteile gegliedert: Backend und Frontend. Hier ist der Vorschlag:
|
|
|
|
---
|
|
|
|
## Projektstruktur
|
|
|
|
### 1. Backend (Go)
|
|
|
|
Das Backend ist in Go geschrieben und folgt den Prinzipien von **Clean Architecture** und **Domain-Driven Design (DDD)**, um die Geschäftslogik klar von technischen Details zu trennen. Dies sorgt für Testbarkeit und Erweiterbarkeit.
|
|
|
|
```
|
|
backend-go/
|
|
├── cmd/
|
|
│ └── server/
|
|
│ └── main.go # Einstiegspunkt der Anwendung
|
|
├── internal/ # Nicht-öffentlicher Code
|
|
│ ├── domain/ # Domänen-Schicht: Geschäftlogik und Entitäten
|
|
│ │ ├── entities/ # Domänenmodelle
|
|
│ │ │ ├── user.go
|
|
│ │ │ ├── company.go
|
|
│ │ │ ├── project.go
|
|
│ │ │ ├── client.go
|
|
│ │ │ ├── activity.go
|
|
│ │ │ ├── employee.go
|
|
│ │ │ └── booking.go
|
|
│ │ ├── repositories/ # Interfaces für Datenpersistenz
|
|
│ │ │ ├── user_repository.go
|
|
│ │ │ ├── company_repository.go
|
|
│ │ │ ├── project_repository.go
|
|
│ │ │ └── ...
|
|
│ │ └── services/ # Domänenservices für Anwendungsfälle
|
|
│ │ ├── user_service.go
|
|
│ │ ├── booking_service.go
|
|
│ │ └── ...
|
|
│ ├── application/ # Anwendungsschicht: API-spezifische Logik
|
|
│ │ └── services/
|
|
│ │ └── api_service.go
|
|
│ ├── infrastructure/ # Infrastrukturschicht: Externe Abhängigkeiten
|
|
│ │ ├── persistence/ # Implementierung der Repositories mit GORM
|
|
│ │ │ ├── gorm_user_repository.go
|
|
│ │ │ ├── gorm_company_repository.go
|
|
│ │ │ └── ...
|
|
│ │ └── config/ # Konfigurationsmanagement
|
|
│ │ └── config.go
|
|
│ └── interfaces/ # Schnittstellenschicht: API-Handler
|
|
│ └── http/
|
|
│ ├── handlers/ # HTTP-Handler für API-Endpunkte
|
|
│ │ ├── auth_handler.go
|
|
│ │ ├── booking_handler.go
|
|
│ │ ├── project_handler.go
|
|
│ │ └── ...
|
|
│ └── middleware/ # Middleware für Auth und Tenant-Isolierung
|
|
│ ├── auth_middleware.go
|
|
│ └── tenant_middleware.go
|
|
├── pkg/ # Öffentliche, wiederverwendbare Packages
|
|
│ ├── logger.go
|
|
│ └── utils.go
|
|
├── tests/ # Tests
|
|
│ ├── unit/
|
|
│ └── integration/
|
|
├── docs/ # API-Dokumentation
|
|
│ └── swagger.yaml
|
|
├── go.mod
|
|
└── go.sum
|
|
```
|
|
|
|
#### Erläuterung:
|
|
- **cmd/**: Enthält den Einstiegspunkt (`main.go`), der den Server startet.
|
|
- **internal/**: Nicht-öffentlicher Code, unterteilt in:
|
|
- **domain/**: Kernentitäten (z.B. `User`, `Company`), Repository-Interfaces und Domänenservices.
|
|
- **application/**: API-spezifische Logik, die Domänenservices nutzt.
|
|
- **infrastructure/**: Technische Implementierungen wie Datenbankzugriff (GORM für PostgreSQL) und Konfiguration.
|
|
- **interfaces/**: HTTP-Handler (mit Gin) und Middleware für Authentifizierung und Multi-Tenant-Isolierung.
|
|
- **pkg/**: Öffentliche Hilfsfunktionen (z.B. Logger).
|
|
- **tests/**: Unit- und Integrationstests.
|
|
- **docs/**: Swagger-Dokumentation für die API.
|
|
|
|
### 2. Frontend (Next.js)
|
|
|
|
Das Frontend nutzt **Next.js** mit **TypeScript** und **FPTS** für funktionale Programmierung. Die Struktur ist typisch für Next.js und fördert Wiederverwendbarkeit.
|
|
|
|
```
|
|
frontend-nextjs/
|
|
├── pages/ # Seitenkomponenten, die Routen entsprechen
|
|
│ ├── index.tsx # Startseite
|
|
│ ├── login.tsx
|
|
│ ├── dashboard.tsx
|
|
│ ├── bookings.tsx
|
|
│ └── ...
|
|
├── components/ # Wiederverwendbare UI-Komponenten
|
|
│ ├── Header.tsx
|
|
│ ├── BookingForm.tsx
|
|
│ ├── ProjectList.tsx
|
|
│ └── ...
|
|
├── lib/ # Hilfsfunktionen und API-Calls
|
|
│ ├── api.ts # Axios-Instanz für API-Anfragen
|
|
│ ├── auth.ts # Authentifizierungslogik
|
|
│ └── ...
|
|
├── styles/ # Stylesheets
|
|
│ ├── globals.css
|
|
│ └── module.css
|
|
├── public/ # Statische Dateien
|
|
│ └── images/
|
|
├── types/ # TypeScript-Typdefinitionen
|
|
│ ├── user.ts
|
|
│ ├── booking.ts
|
|
│ └── ...
|
|
├── tests/ # Tests für Komponenten und Seiten
|
|
│ ├── components/
|
|
│ └── pages/
|
|
├── next.config.js
|
|
├── package.json
|
|
└── tsconfig.json
|
|
```
|
|
|
|
#### Erläuterung:
|
|
- **pages/**: Seiten der Anwendung (z.B. `dashboard.tsx` für `/dashboard`).
|
|
- **components/**: Wiederverwendbare UI-Komponenten (z.B. `BookingForm.tsx`).
|
|
- **lib/**: Hilfsfunktionen, z.B. für API-Calls mit Axios.
|
|
- **styles/**: Globale und modulare CSS-Dateien.
|
|
- **public/**: Statische Dateien wie Bilder.
|
|
- **types/**: Typdefinitionen für Typsicherheit.
|
|
- **tests/**: Tests mit Tools wie Jest oder Cypress.
|
|
|
|
---
|
|
|
|
## Multi-Tenant-Unterstützung
|
|
|
|
Die Multi-Tenant-Fähigkeit wird durch eine **Tenant-ID** (z.B. `company_id`) in den Datenbanktabellen umgesetzt. Das Backend verwendet ein **tenant_middleware.go**, das sicherstellt, dass Benutzer nur Daten ihres eigenen Tenants sehen, indem die `company_id` in jeder Anfrage geprüft wird.
|
|
|
|
## API-Dokumentation
|
|
|
|
Die API wird mit **Swagger** dokumentiert, gespeichert in `backend-go/docs/swagger.yaml`. Dies bietet eine klare, interaktive Übersicht der Endpunkte.
|
|
|
|
## Entwicklung mit LLMs
|
|
|
|
Für die Entwicklung mit LLMs ist der Code in kleine, klar benannte Dateien aufgeteilt (z.B. `user.go`, `booking_service.go`), die jeweils eine spezifische Aufgabe haben. Dies erleichtert LLMs das Verständnis und die Generierung von Code.
|
|
|
|
---
|
|
|
|
## Fazit
|
|
|
|
Diese Struktur ist modular, übersichtlich und erweiterbar. Sie nutzt bewährte Praktiken für Go und Next.js, unterstützt Multi-Tenant-Fähigkeit und ist durch die Aufteilung in kleine Module ideal für die Entwicklung mit LLMs. Wenn du Anpassungen oder mehr Details möchtest, lass es mich wissen! |