Thoughts about scalable code structure based on developer as user philosophy combined with iterative design using AI.
Cover - Imaginary futuristic device running clock:) Who knows how devices end up looking? 👀 Generated in Leonardo AI and computer.tldraw.com
In a series of articles, I would like to share my thoughts about how to structure codebase and use different approaches for architecture structure scaling through different stages of product growth.
App Architecture Series
Part 1 — Intro Notes — You are here:)
Part 2 — Stage 1 and 2 — Next
Part 3 — Stage 3,4,5 and Conclusion (in Progress)
Note One. Inspire and adapt.
All my thoughts are based on my own experience from having made some decisions and over time watching some of those decisions prevail or fail. It is my reflection of what is possible to do and how, not strict guidelines to follow, but rather instead — to inspire and adapt.
It may or may not complement in some cases general development approaches, especially in large companies or recently published https://docs.flutter.dev/app-architecture amazing guide.
Instead, I will focus only on startup early stages, for those who take a journey starting from a single Flutter developer and look for a way ahead to scale it up to several (let’s take a five-six) developers in the company when needed.
Second Note. Different perspective.
Product development and ordered product in-studio paths can be completely different, so my advice is to skip stages if needed, aligning with your personal experience.
Third Note. Developer as a user.
During texts, I will treat developer as a user — imagine project code structure via folders and file structures first — in the same way most developers look at their code. For me, it was a great discovery that it is the most convenient way to hand your work over for maintenance or feature changes.
Part of that discovery was watching a video of Clean Architecture and Design , other parts include Domain Drive Development or DDD , Test Drive Development or TDD, and just a development routine, and I hope to continue this journey along the way:)
Simply put, you define the code structure, which declares how your code will communicate, and then apply your preferred architecture patterns to it.
Fourth Note. Prompts.
As of January 27, 2025, it is evident that many developers utilize AI tools to explain code or quickly prototype solutions. Therefore, when the term ‘prompt’ is mentioned, it refers to a saved question or response generated by an AI tool in text format.
Fifth Note. AI.
Before development or at any stage.
Create your own AI preferences / agent-rules for your favorite AI tool and project-wide preferences, so other developers can use it in the future. For example, if you use Cursor, you can find useful rules https://cursor.directory.
Keep in mind that it should always be part of your architecture — you will iterate over these rules, roll back, write, rewrite, test it, etc. So, treat it just as a part of your codebase.
In the same time, since this is quite a new approach, it’s a quite experimental technique to use it and may produce unpredictable results. Be careful and always rely on your skills.
Sixth Note. Terminology.
Let’s define the meanings of several key terms (while there are many, we need to focus on these to ensure a clear context for the notes):
1. End user
a user, who uses the application on any platform available — iOS, Android, macOS, Windows, Linux, web, etc.
2. Domain
logically defined and restricted by its subject area (scope) in your application, defined by end user experience combined with application functionality.
https://en.wikipedia.org/wiki/Domain_(software_engineering)
Complex App Example:
Imagine a financial app and you are the end user.
You may expect the following logical domains:
- Intro. Guide how to use the application, or quiz, or news — some screens that may appear before Home appears.
- Home. Specific to home functionality, most frequent features that the user uses. This domain may or may not use features from other domains. As the user expects it to be fast to use, let’s call it fast functions experience.
- Payments. You may expect that the main screen will lead to other screens, such as bank providers, digital transfers etc.. but all these screens will be logically tied to a single subject (scope) of payment experience.
- Profile. The end user can expect that he can sign in/ sign out, can delete his account, go to privacy settings, check some documents. Let’s call it profile experience.
- Support. This domain may have a screen with chat, it may have different conversations in different screens, but at the same time all of them will define a subject of support experience.
To develop each domain, you will have to capture how end users or experts, specialists experience it or experience it by themselves.
Or in other words — you will have to define and research domain knowledge.
3. Domain knowledge
“is knowledge of a specific discipline”, captured from domain experts/specialists by analytics, designers or through iterative design, your own experience or work.
In our case it would be the experience of the end user who uses your app.
https://en.wikipedia.org/wiki/Domain_knowledge
4. Flow
a one screen or series of screens, pages or views orginized in certain direction from user perspective. For example — Auth Flow.
5. Screen
a widget, partially or fully covering a screen, consists of features placed on that screen / page / view.
Personally, I like the concept to treat any screen as a page as a view, which can be seen fullscreen or take part of the layout which is buildable with nested navigation (go_router navigation in Flutter) and similar to how JS frameworks work in the web (vue-router).
6. Feature
“distinguishing characteristic of a software item (e.g., performance, portability, or functionality)”.
Applying to the domain, let’s define it as a single-purpose particular capability/functionality, which in combination with other features helps the end user to experience the domain as a whole.
https://en.wikipedia.org/wiki/Software_feature
Thank you for your time, to continue, use a link below.
Please don’t forget to share your thoughts in comments:) it really helps the algorithms give this article to others to read, and it would be great support from you:)
App Architecture Series
Part 1 — Intro Notes — You are here:)
Part 2 — Stage 1 and 2 — Next
Part 3 — Stage 3,4,5 and Conclusion (in Progress)
Top comments (0)