5.3 KiB
5.3 KiB
FinlyticApp — Architecture Guidelines & Engineering Standards
Dieses Dokument definiert die verbindlichen Architektur- und Entwicklungsstandards für die FinlyticApp (Dart / Flutter Cross-Platform Client für Android, iOS und Web).
1. Grundprinzipien & Dateistruktur
Das Projekt folgt einer strengen Feature-Driven Clean Architecture. Dadurch wird eine vollständige Entkopplung von Benutzeroberfläche, Geschäftslogik und Datenquellen gewährleistet.
📏 Dateigröße & Struktur-Limits
- Maximal 150 bis 200 Zeilen pro Datei: Wenn eine Datei diese Grenze überschreitet, muss sie in kleinere, fokussierte Einheiten refactored werden (Single Responsibility Principle).
- Eine Hauptklasse pro Datei: Helper-Klassen gehören in eigene Dateien, es sei denn, sie sind
privateund ausschließlich lokal relevant. - Kompakte
build()-Methoden: Diebuild()-Methode dient nur der Anordnung von Sub-Widgets und darf selten länger als 30–40 Zeilen sein.
📁 Verzeichnisstruktur (lib/)
lib/
├── core/
│ ├── network/ # ApiClient, MQTT-Service, WebSockets
│ ├── theme/ # Finlytic Dark Glassmorphism, Typography, Colors
│ ├── utils/ # Formatierer (Währungen, Prozentangaben, Datum)
│ └── widgets/ # App-weit genutzte UI-Komponenten (Buttons, Modals)
├── features/
│ ├── dashboard/ # Dashboard-Overview, Analytics-Cards
│ ├── news/ # Feed, Pagination, Sentiment-Analysen
│ ├── favorites/ # Favoriten-Grid, Watchlist
│ ├── calendar/ # Corporate Calendar, Earnings, Dividenden
│ ├── trades/ # Trade-Signale, Automatische Trades
│ ├── admin/ # User-Verwaltung, System-Settings (Admin-Only)
│ └── asset_detail/ # Fundamentaldaten, TA-Chart, Finance-Metrics
└── main.dart # Entry Point & Service Locator Initialization
2. Clean Architecture Layering
Jedes Feature im features/-Ordner wird intern strikt in drei Layer unterteilt:LayerVerantwortlichkeitErlaubte Abhängigkeiten1. PresentationUI-Komponenten, Screen-Layouts, Consumer von States.Greift nur auf Logic (BLoC/Notifier) zu. Keine direkten API/DB-Calls!2. Domain / LogicBusiness-Logik, State Management, UseCases, Entities.Absolut frei von flutter/material.dart! Nutzt Repositories als Abstraktion.3. DataAPI-Clients, DTOs, Local Caching, MQTT-Stream Handlers.Implementiert Repository-Interfaces aus dem Domain Layer.
3. Widget-Architektur & Sub-Widget Auslagerung
❌ VERBOTEN: Helper-Methoden für Widgets (_buildX())Unter keinen Umständen dürfen Methoden innerhalb von Widget-Klassen definiert werden, die ein Widget zurückgeben:Dart// ❌ FALSCH: Baut keinen eigenen BuildContext/Lifecycle auf und erfordert Rebuilding des gesamten Mutter-Widgets!
Widget _buildHeader() {
return Container(
padding: const EdgeInsets.all(16),
child: const Text('Dashboard'),
);
}
✅ PFLICHT: Auslagerung in eigene StatelessWidget KlassenJedes logische Teilsegment der Benutzeroberfläche muss als eigene Klasse ausgegliedert werden:Dart// ✅ KORREKT: Saubere Performance, eigener BuildContext, optimierter Element-Tree
class DashboardHeader extends StatelessWidget {
const DashboardHeader({super.key});
@override
Widget build(BuildContext context) {
return Container(
padding: const EdgeInsets.all(16),
child: const Text('Dashboard'),
);
}
}
⚡ Performance-Regeln für Widgets:const Konstruktoren: Jedes Sub-Widget muss wenn möglich einen const Konstruktor haben, um unnötige Re-Renders im Widget-Tree zu verhindern.Keine Business-Logik im UI-Widget: Widgets reagieren ausschließlich auf übergebene Daten oder States und leiten Nutzerinteraktionen über Callbacks / BLoC-Events weiter.
4. Data Classes & Code-Generierung
Immutability: Alle Models, DTOs und States müssen unbeeinflussbar (immutable) sein.Freezed & JSON Serializable: Das manuelle Schreiben von fromJson, toJson oder copyWith ist untersagt. Es wird freezed zusammen mit build_runner eingesetzt.Dartimport 'package:freezed_annotation/freezed_annotation.dart';
part 'asset_model.freezed.dart';
part 'asset_model.g.dart';
@freezed
class Asset with _$Asset {
const factory Asset({
required String isin,
required String name,
required double currentPrice,
required String currency,
}) = _Asset;
factory Asset.fromJson(Map<String, dynamic> json) => _$AssetFromJson(json);
}
5. Responsive & Adaptive Navigation LayoutFinlyticApp wird plattformübergreifend betrieben und muss sich dem Screen-Format anpassen:Mobile Breakpoint (< 800px): Anforderung von Material NavigationBar (Android) / Cupertino Tab Bar (iOS) am unteren Bildschirmrand.Web / Desktop Breakpoint (>= 800px): Automatische Skalierung auf ein linkes Tab-Menü (NavigationRail / Sidebar).Keine starren Dimensionen: Nutzung von LayoutBuilder, Flexible und Expanded, um Überläufe (Pixel Overflow) auf schmalen Displays zu verhindern.6. Linter Standard (analysis_options.yaml)Alle Entwickler müssen die folgenden Linter-Regeln in der analysis_options.yaml einhalten:YAMLlinter:
rules:
- prefer_const_constructors
- prefer_const_declarations
- prefer_final_fields
- prefer_final_locals
- avoid_unnecessary_containers
- sizedbox_for_whitespace
- use_build_context_synchronously
- always_declare_return_types