This is the only layer that knows about Flutter. With code generation support you can easily set it up in this way, and you can remove a lot of code duplication.Īt the bottom, there is the Presentation Layer.

In this case, the Data Layer can be excessive and a more reasonable way could be to allow the Business Logic Layer to communicate directly with the API layer and reuse its DTOs as models. As I’ve mentioned earlier, our backend is pretty common, so if you have an “app-centric” backend (it often makes sense if the mobile app is the main product of your company), you probably have a pretty close match between backend and app models. Next comes the Data Layer - this is where these interfaces are implemented, and this is the only layer that communicates with the API. Inside of each feature we have a vertical hierarchy of some common layers with the Business Logic Layer on top (where we define our app models and interfaces for fetching and posting data). Each feature can be viewed as a standalone module with more or less complete functionality, so it should communicate with other features as little as possible.įor example, one feature can be “Task management”, another one: “Messaging system” or “Profile management”. All the other functionality is divided into a set of horizontal features. This is a common layer that is used across the whole app.

If I would have been asked to describe these principles in just a couple of words, I would go with layers and strict directions of dependencies between these layers.įor us, one of the major layers is the API layer, where we define DTOs and methods for communication with the backend. Mainly, we follow Clean Architecture principles. It’s important because it has an impact on the overall app architecture. Another thing, which may be not so common for the majority of apps, but is pretty standard in the enterprise world: the backend serves the whole set of products, it’s not “app-centric” - it solves a lot of different tasks, so the models and flow on the backend don’t really match the models and flows that we define in the mobile app. It’s used across all our applications and has implementations for mobile and web. First of all, we have a fully custom UI, or more precisely, a custom design system (that stays on the same level of hierarchy as Material Design for Android or Cupertino Design for iOS). There are, however, a couple of things that are not so common. This is just a common B2B app with the functionality you would normally expect from it: authentication, profile management, messages and tasks, forms, and communication with backend API. In this article, I would like to share some problems we’ve encountered so far, describe the architecture we’ve eventually come to, what libraries we’ve found useful, and eventually, I’ll answer the question: was it a good idea to re-write our app from scratch using Flutter?įirst of all, let me quickly describe the functionality of the application. Initially, it was written as a native application for iOS and Android, but about 1.5 years ago we decided to migrate it to Flutter. Also, we have a set of smaller products, one of which is a mobile application intended mainly for housekeepers and other hotel staff. Our main product is a large and complex Property Management System. This is a text version of my presentation at DartUP 2020.

Flutter widgets factory