Architectural Remarks

Overview

Control flow

1. The user interacts with the View.
2. The View collects it into a RequestObject which is passed to the Controller.
3. The Controller converts the RequestObject into a RequestModel which is passed to the Use Case interactor.
4. The Use Case interactor processes the RequestModel and, if no exceptions were thrown, returns a ResponseModel which is passed to the Controller.
5. The Controller converts the ResponseModel into a ViewModel which is passed back to the View.
6. The View might pass the ViewModel to a Presenter for conversion-heavy operations.
7. The user sees the result of their interaction in the View.

Note that RequestObjects, RequestModels, ResponseModels, and ViewModels are DTOS and should not contain any logic.

RequestModels and ResponseModels are defined by the respective Use Case interactors. RequestObjects and ViewModels are defined by the respective *Controllers.

An Use Case interactor might require no RequestModels and might return no ResponseModels. Controllers behave likewise.

Design patterns and Principles

1. GUI version

• The graphical user interface version of the application is currently using Singleton (which is not recommended). The application has a unique instance of a StageManager, which keeps only one stage (window) on the screen, and loads the proper UI (fxml file) for each use case.
• This version follows the MVC pattern, but not strictly. In some occasions a presenter is added for easier implementation or simpler code.
• This version is an implementation of Clean Architecture

???

• Borrows ideas from Clean Architecture, which involves multiple well-known others like DDD, Repository Pattern, Hexagonal/Onion/Layered Architecture, etc.
• Manual Dependency Injection with the Repository Pattern
• The Builder Pattern aids DTOs construction
• Asynchronous Programming (with CompletableFuture<T>) & Multithreading (with ExecutorService)
• ApplicationContexts simulate the Facade Pattern
• Reflection
• Trie, Directed Acyclic Subsequence Graph, etc.

Tech stack

Limitations

Sacrifices

• Decoupling of controllers and presenters for better encapsulation
• SoC of SynchronizedGenerators for less intensive, asynchronous near real-time synchronization over batch synchronization

Future considerations

References