A Step Up in your Flutter Architecture

Learn the step that creates a code base that can scale into a team of developers

What we’ll cover in this Post are concrete steps you can take to separate your Business Logic from your Application Code.

The fun of being a programmer comes from solving problems, creating something new, or improving something old. Having an unmaintainable code base makes achieving any of the three programming goals much more frustrating. Separating your Application Code from your Business Logic is a step that will increase the maintenance of your code base by a big percentage.

Most code bases fail to do this due to a lack of knowledge but also not seeing the dangers in not doing it.

If you don’t separate Business from Application Code you will create a tightly coupled coding nightmare

What you’ll learn through this post is:

• The Definition of Application Code

• When to separate the two

• How to Separate the two

The basics cannot be overstated. We know we need a loosely coupled code base to make things more manageable. This is one of the most crucial steps in getting your codebase there.

The goal of this post is to provide clear and concrete guide on what you can do to get started.

What is Application Code

In the previous post, I shared the definition we’ll use for Business Logic. As it was defined there, it’s the code in between the user’s interaction with the UI and the Code that does the actual work (make an http request, write to a database, save a file to disk). The code that does that actual work is called Application Code.

You can think of the Business Logic as the manager and the Application Code as the worker. The work to be done, at the lowest level, is done by the Application Code. Instead of me finding tons of metaphors to use I’ll detail some examples of application code:

• Making an HTTP request: Compiling the request, setting the headers, building the URL, making the request, reading the response, reading the status code, and serializing into your decided model.

• Writing or reading from a database: Making the connection to the database, compiling the SQL statement, starting the transaction, serializing the data.

• Reading a file from disk: Creating the connection to the file, reading the data, serializing the data, and turning it into a usable model.

• Calling into a package or library: Another form of Application Logic is when you use another package that does the work for you.

If you visualize this, as a tree, you have the user at the top as the root, then you have your state below it on a layer, in between you have your Business Logic, and finally, you have the actual work being executed, your Application Logic.

When to separate Business and Application Code

When it comes to separating the two I would start by saying, get your code working first. Applying these while solving a problem you don’t know how to solve will not be helpful. When your code works and you’re happy with your solution I would advise applying a subset of questions I shared to determine if you should Split your UI and State Code, specifically questions about the project or the code you’re working in.

1. What is the intention of the project or code?

2. What is the time commitment of this project? How long are we going to be building and expanding this code? (2 weeks, 1 month, 1 year, 5 years)

3. What stage is the project or code in? (Fresh, MVP, alpha, production)

4. How many developers will work on the project or interact with this code? (single, team, multiple teams)

So with those questions. Here are the specific times I have decided to invest in separating my business code from my application code:

1. When the questions above indicate one of the following:

   1. The goal is for long-term building and usage of the code

   2. More than 1 developer will have to modify the code

   3. The project is being used by users (alpha→production stages)

2. When I want to remove dependencies from my Business Logic

3. When I want to write unit tests for my Business Logic

How to separate Business and Application Code

This process is often simpler than separating your UI and State code. At this point, it’s all code separate from your UI which means there’s no Flutter framework code involved. It’s pure Dart. This makes the process quite simple. It’s similar steps I shared in last week's post.

1. Identify the Application Code: All the code that’s doing real work

2. Split into Single Responsibility functions: Move that code into functions

3. Move functions into class: Take all the single responsibility functions above and move them into their own class

4. Create an instance of your class where the Business Logic is and call your functions from there

5. BONUS: Register your class that contains the Application Code with an Inversion Container and get it from there instead of constructing it in the class

If you’re at this point in the code base you have done a great job with your code. These are not the only things required for creating a good code base but they are the first and arguably the most important steps. It means that the code is easier to expand, easier to understand, and will allow you to scale your software engineering efforts outside of just a single dependent developer.

This is part 3 of a 4-step system:

• Step 1 is to Split your UI and State code

• Step 2 is to Split your State and Business Logic

• Step 3 is to Split your Business Logic and Application Code (This one)

Step 4 is to invert dependencies in Application Code, which I cover in next week's newsletter.