Flutter for Enterprise | A Cleaner Approach [1/2]

The resources needed to develop a feature doesn’t surge significantly with respect to time in long run

Problem 1 : Responsiveness is not enough

Although flutter ships responsiveness straight out of the box and can adapt to different screen sizes easily, it is still not enough as different platform may take different path of evolution. In other words, designers might want to give different user experience on different platform on the basis of screen sizes. For example the billing and shipping step during a typical checkout process can be merged into a single screen while targeting platform with bigger screen sizes. Similarly, it can also be splitted into separate screens while targeting mobile platform with smaller screen sizes.

Problem 2 : Business logic needs to be composable

As different platform can evolve differently, we might end up with different UI per platform for same feature. So we want reuse the business logic in such a way that we can compose the existing one to create bigger business logic. For instance, referring to above example of billing and shipping process, we would require individual business logic for handling billing and shipping tasks when the process is splitted. Similarly, when the process is merged as a single feature we want to compose the existing business logic instead of writing it from scratch. This allows us to reuse the already tested business logic and integrate with minimum effort and time.

Solution : Adopting Domain Driven Design

Overview:

Domain Driven Design is set of principles that pushes domain i.e. business logic/policies at the core and rest of implementation detail layered on top of it on different level. There are different variants of this approach such as Onion Architecture, Ports and Adapters, Hexagonal Architecture and Clean Architecture. Although the overall intention is the same, we’ll be considering clean architecture for demonstration as it is fairly renowned in mobile development community.

Clean Architecture
Domain Layer

“We want to post user information when user presses a submit button”

So the usecase/interactor will know what to post on the response of button tap event but doesn’t know exactly how to post to remote server. For this it delegates the responsibility to corresponding layer that abstracts underlying data source for example a Data Access Object or Repository or any other similar design pattern.

Solution to “Responsiveness is not enough”

To address this problem, we will maintain separate UI+Presentation Layer according to our need. For instance, let us consider the following cases with their corresponding separations:

Three different presentation layer for each separations.
Different presentation layer for all available platforms.

Solution to “Business logic needs to be composable”

“For mobile, breakdown the process into two step on separate screens while on web implement it as a single process on single screen.”

Flow:

Flow for Mobile Platform
Flow for Non-Mobile Platform
UML class diagram for use-case types as per the requirement specs (1)

“The billing and shipping address information needs to be identical.”

In other words, after posting billing and shipping information, we need to validate the address provided in different format mentioned in both and allow user to proceed only if we get success response from the server.

UML class diagram for use-case types as per the requirement specs (2)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store