> For the complete documentation index, see [llms.txt](https://kwanjoong-dev.gitbook.io/unity-ui-storyboard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kwanjoong-dev.gitbook.io/unity-ui-storyboard/en/screensystem/undefined/undefined-2.md).

# Class design

* Based on MVPs, common or bloat-prone processing, such as communication and screen transitions, is handled by other classes at the right time.
* The lifetime of a Model only lasts within its screen, and persistent data is kept in the Repository.
* There is one Presenter for each screen.
* As you have more elements on the screen, Presenter tends to get bigger, so we break out the big processing into separate classes to reduce the processing Presenter does directly.
* Model and View are also one in the default 1 screen, but split them if the screen is bloated or if the on-screen elements are independent.

<figure><img src="https://759830598-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgcsVVZgG86GNRWlX1FWj%2Fuploads%2Fgit-blob-f0875c801e5107258b5bbff0f26d85ee0185ac31%2FScreenSystem.png?alt=media" alt=""><figcaption><p>ScreenSystem Architecture</p></figcaption></figure>

* Names like UseCase and Repository adopt terminology used in other architectures, such as clean architecture, but are not consistent with clean architecture.
* They are designed to reference clean architecture and other architectures, but with the goal of reducing complexity and ease of use.