Application Reference Architecture Design

Overview 

Previously, all the UX/UI, business logic and integration were directly interwoven into the application, meaning that any changes made the upgrade path, maintenance and support difficult or near impossible. The Banking Application Reference Architecture structures the application definitions and code into distinct layers with strict rules on how to extend them. The goal is to preserve the upgrade path and maximize the sharing of objects and components. This is based on the typical MVC (Model View Controller) architecture, but with additional controller and model abstraction layers.

With flexibility comes complexity.  While the "previous" model may be more development productive, but the longer-term cost of maintenance and support is much higher. The decoupled MVC architecture requires good tooling support to highlight the interactions, shared components, dependencies and extensions.

Tooling	Layer	Role
Quantum Visualizer	Form	The UI definition screen.
	View Controller	Responsible for processing the UI view life-cycle events and binding data to the UI elements.
	Presentation Controller	Acts as an intermediary between the View and the Business controller layer to properly format the request and handle exceptions. In some simple cases, the View Controller may interact directly with the Business Controller.
	Business Controller	Handles all common validations, navigation control, external client API calls, data operations and synchronizations. Whilst the majority (95%) of business logic resides in the Quantum Fabric Server layer, some dynamically-configurable logic may reside locally on the Client Application.
	Model	Generated code based on the Object Service handling all the CRUD and data transfer operations between the Client App Business Controller and Quantum Fabric Object Services Integration layer.
Quantum Fabric (Server)	Object Services	Business Object definitions based on the banking data model that defines the data attributes, interface, and operations allowed. For example, Accounts, GetAccountList. There may also be pre processing and post processing functions to handle more complex business logic, analytics, security, etc.
	Mapping and Orchestration	The mappings and orchestrations between the third-party back-end services and the generic Banking Object Services.
	External Integration	Third-party client SDK or Back-end REST, or SOAP service definition.

Model Layer

The Model component includes Model Objects and Object Controller (DAOS) and signifies shape of the data and the business logic. The Model objects (Accounts, User, Transfer and Payment) retrieve and store model state in a database.

Business Logic Layer

The Controller component is represented by Business Logic layer that  includes Business Controllers and Command Handlers. The Business Controllers receives requests from the View (UI/UX) controllers. The Command Handlers executes the business logic and send the requests to Model objects. The business response is sent back to View controllers.

Presentation Layer

The UI/UX component includes Presentation Controllers and UI Binders. The UI/UX component represents a user interface. The Presentation Controller handles the user request.

Typically, a user interacts with MDAFormController that handles a user request. Every user request invokes an event. The event is received by the event handler (Presentation Controller) and sent as a command to the Business Logic Layer. The request is handled by the Business logic layer and sent to the Model Object layer to fetch the user response from the database. The response is sent back to Presentation Controller. The Presentation Controller renders the appropriate view of the model data as a response to the user.