Learn
Architecture and boundaries
See where Ark MVP begins, what each role owns, and why no business framework is built into the packages.
Architecture and boundaries
Ark MVP constrains the presentation flow without prescribing how the application creates, stores, or executes business logic.
Four roles
| Role | Receives | Produces | Owns |
|---|---|---|---|
| Application composition | Existing business objects | ModelBinding<Model> | Business objects and their lifecycle |
| Model | Current business snapshots and allowed operations | One immutable feature input | No resources |
| Presenter | Model and presentation environment | ViewState, actions, ViewEffect | Presentation-local state and resources |
| View | ViewState and Presenter API | Rendered UI and user intent | Framework rendering resources |
Dependency direction
ark_mvp has no dependency on a state manager, DI container, storage package, or UI framework. ark_mvp_flutter adds only Flutter hosting. UseCase Forge can supply business state through application composition, but neither MVP package depends on it at runtime.
This preserves two valid uses:
- a feature based on one or several UseCases;
- a feature based on any other typed application-state boundary.
What the boundary rejects
A feature Model should not expose an HTTP client, database connection, or global container merely because composition can access them. It should expose the business information and operations the feature is allowed to use: reload(), saveDraft(), or signOut().
Likewise, View should not interpret execution phases, merge several managers, or localize raw domain values. These are Presenter responsibilities because they determine presentation meaning.
No hidden ownership
ModelBinding observes externally owned sources. PresenterSession owns one Presenter lifecycle. A Flutter MvpView owns its Presenter but never closes the UseCase or manager captured by the binding. The object that creates a resource remains responsible for closing it.