The Binder Architecture

The Binder Architecture is a declarative architecture for iOS development inspired by MVVM and VIPER. It is an attempt to take the best ideas of MVVM and VIPER and implement them without the boilerplate code that the two architectures, especially the latter, suffer from.

The central idea of the Binder architecture is implementing application logic as a function, as opposed to an object. In place of the ViewModel or Presenter, The Binder Architecture defines a function called the binder. Such approach enforces declarative application logic that provides all the benefits of declarative paradigm and results in a significant reduction of the boilerplate code that can be found in MVVM and VIPER.

Overview

The architecture defines three main layers:

1. Business logic layer represents all the code that defines what the app can do and how to do it. It can be comprised out of many first or third party components. It exposes all of its functionality to other layers of the architecture through a number of components called Services.
2. Application logic layer represents a bridge between the business logic and the view. It knows when and how to presents the UI, loads the data using the business logic services, formats the data for the display, displays the data using the view and handles users actions by notifying appropriate Services. The central component of this layer is the Binder function.
3. View layer defines UI. It is a declarative layer comprised of UIView and UIViewController subclasses.

Business Logic

Every good app provides some kind of a value to the user. Sometimes it does that by exposing a web service, sometimes by solving problems locally on the device and often by a combination of the two.

An app can communicate with web APIs, different business services, databases or other data persistence solutions, system services or device sensors and various other things. All of those will have their entities, managers and other kinds of types and objects. A code that interacts with them and builds on top of them is often referred to as the business logic. That is the bottom-most layer of our architecture.

One could write a book on how to properly implement the business logic layer and even that might not be enough. Thankfully there is a simple rule of thumb that we can use to define boundaries of the layer: imagine that we are making a cross-platform app (i.e. an app that can run on iOS, Android, TV, watch and/or desktop) and ask ourselves: “What is the code that can be shared across all of the platforms?” The answer is the code of the business logic layer.

The business logic layer exposes its functionality through a number of Services. Each Service is responsible for its own concern. For example, a webshop app could have ProductService, ProductSearchService, CartService, CheckoutService, etc. A CartService would represent a cart and be able to manage it by providing methods like addProduct, removeProduct, empty, etc.  The Services would be accompanied by the Entities they work on like Product, Cart, User, etc. It is recommended to model those as value types like structs and enums when possible.

Here is a simple example of an entity and a service.

 

We are showing only the public interface, not the implementation. It probably communicates with some web API and it might use CoreData for the persistance, but we don’t really care about its implementation. We only need to know that it represents our business logic on top of which we are building our app. Now, you have probably noticed the Signal type there. We will be using ReactiveKit and Bond to demonstrate functional reactive aspects of the architecture, but other solutions will work well too.

https://github.com/DeclarativeHub/TheBinderArchitecture