Skip to content

Commit 64ec720

Browse files
committed
docs(web-dashboard): add architecture overview page
- Create new page explaining the layered architecture and core principles - Describe presentation, business logic, repository, and data layers - Highlight key patterns like BLoC and dependency injection - Mention shared packages and their importance
1 parent 9aa644f commit 64ec720

File tree

1 file changed

+30
-0
lines changed

1 file changed

+30
-0
lines changed
Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
---
2+
title: Architecture Overview
3+
description: An overview of the architectural patterns and structure of the Flutter web dashboard.
4+
---
5+
6+
import { Aside } from '@astrojs/starlight/components';
7+
8+
The Flutter News App Web Dashboard is built upon a clean, scalable, and maintainable architecture that separates concerns into distinct layers. This approach, combined with the use of shared packages, ensures that the codebase is both robust and easy to extend.
9+
10+
### Layered Architecture
11+
12+
The dashboard follows a classic layered architecture, ensuring a clear separation of responsibilities:
13+
14+
1. **Presentation Layer (UI):** This is the user-facing layer, built with Flutter widgets. It is responsible for displaying the UI and capturing user input. It is kept as "dumb" as possible, meaning it contains minimal logic and simply reflects the state provided by the Business Logic Layer.
15+
16+
2. **Business Logic Layer (BLoC):** This layer contains the application's state management and business rules. We use the **BLoC (Business Logic Component)** pattern to manage the flow of information from user events to UI states. Feature-specific BLoCs (e.g., `ContentManagementBloc`, `DashboardBloc`) orchestrate data from the Repository Layer and emit states for the UI to consume.
17+
18+
3. **Repository Layer:** This layer abstracts the origin of the data. It provides a clean, simple API for the Business Logic Layer to access data, without needing to know whether the data is coming from a remote API or a local in-memory source. This is a key part of our strategy for testability and environment flexibility.
19+
20+
4. **Data Layer (Clients):** This is the lowest layer, responsible for the actual data retrieval. It consists of `Client` implementations that communicate with external sources. For the dashboard, this means either an `HttpDataClient` that makes requests to the API server or an `InMemoryDataClient` used for the demo environment.
21+
22+
<Aside>
23+
The Repository and Data layers are not implemented directly within the dashboard. Instead, the dashboard consumes them as shared packages, which are used across the entire ecosystem (including the mobile app and API server).
24+
</Aside>
25+
26+
### Core Principles
27+
28+
- **Dependency Injection:** Repositories and other services are provided to the widget tree using `RepositoryProvider` and `BlocProvider`. This decouples our components and makes them highly testable.
29+
- **Immutability:** All data models and BLoC states are immutable, which leads to more predictable state management and reduces the risk of side effects.
30+
- **Shared Packages:** The dashboard leverages a suite of shared packages for core functionality (e.g., `core`, `data_repository`, `auth_repository`, `ui_kit`). This promotes code reuse and consistency across the entire project ecosystem.

0 commit comments

Comments
 (0)