Healsense: A Flutter Medication Reminder Built on DDD, Drift, and Riverpod

What Healsense Actually Solves

Healsense targets a common problem: people forgetting to take medications on time. The app is a medication reminder for Android, published on Google Play under the package healsense.reminder.app. The README frames it as an open-source application in production, meaning the code you see is what runs in a real app, minus the Google Maps API key. For whom is it intended? The README says the project will have a paramount effect on your progress learning Flutter. That sentence is promotional, but it points to the real audience: Flutter developers who want to study a full app structure, not just a widget demo. The app itself is a consumer tool, but the repository is more valuable as a teaching artifact than as a ready-to-deploy product.

The DDD Architecture in Five Layers

The repository is organized around a DDD (Domain-Driven Design) approach. The README lists five layers: Application, DI, Domain, Infrastructure, L10N, and Presentation. That is six items, but the text describes five conceptual layers. The Domain layer holds core value objects, failures, repository interfaces, and entities, with a rule that one class has one responsibility. The Infrastructure layer contains data sources, split into locals (database) and remotes (API), plus repository implementations, models, and services. The Application layer is the state management layer, using Riverpod binding, states, and notifiers. The Presentation layer is only pages and widgets. This separation is meant to ensure the UI does not care about the data layer, and to allow changing the database type later without touching higher layers. The README also mentions separating each layer into different packages as a future possibility, which is not yet done in the repository. This is a classic DDD trade-off: the structure adds indirection, but it pays off when the data source changes.

The Tech Stack: Drift, Riverpod, Go Router, RxDart, Freezed

Healsense uses a specific set of Flutter packages. Drift is the database library, which is a reactive persistence layer built on SQLite. Riverpod handles state management, and the README specifies that the Application layer uses Riverpod binding frameworks, states, and notifiers. Go Router manages named routes. RxDart brings reactive extensions, likely for combining streams from Drift and other sources. Freezed generates immutable classes and unions, which fits DDD value objects and failures. Service locator is implemented via injectable and get_it, as the README states. This combination is coherent: Drift exposes streams, RxDart manipulates them, Riverpod consumes them, and Freezed reduces boilerplate. The choice of service locator over plain constructor injection is a design decision; get_it is common in Flutter but can hide dependencies if overused. The README claims this eliminates rigid dependencies, which is true only if the locator is confined to a composition root.

Getting It Running: The .env Requirement

The README gives one concrete setup instruction: every code structure is open source except GOOGLE_MAPS_API_KEY. To run the app, you must create a .env file at the top of the project and put that key inside it. No other setup steps are described beyond 'Get dependencies and generate necessary files.' The README says the project will handle the generation of required files for onboarding, but it does not specify commands like flutter pub get or build_runner. This is a gap. For a project using Freezed and injectable, you would normally run build_runner to generate code. The README does not confirm that. The .env file is used for the Google Maps key, but the README does not explain how the key is read (e.g., via flutter_dotenv). You need to inspect the repository to find that. This is a real barrier for a quick start.

Localization and Resources: The L10N Layer

The project includes an L10N layer, which is part of the architecture list. The README says localization is handled using a library, and it directs readers to follow a guide to configure language files, but it does not name the library. The resources section states that all images, fonts, videos, and other assets must be placed in an assets class. This is a common pattern in Flutter to centralize asset references and avoid hard-coded strings. The L10N layer sits between the Presentation and Domain layers, which is a sensible place for translation strings. The lack of specifics about the localization library is a documentation weakness, but the existence of the layer shows the author considered multi-language support. For a medication reminder app, localization matters because medical instructions are sensitive to language errors.

The Missing Google Maps Key: A Production Contradiction

The README says the app is in production, but it requires a GOOGLE_MAPS_API_KEY that is not provided. This is not a flaw in itself; many production apps keep keys secret. But it does mean the repository is not runnable out of the box. You must obtain a key from Google, which typically requires a billing account and enabling the Maps SDK. The README does not mention any of that. This is a genuine limitation for someone who wants to evaluate the app quickly. Also, the app's connection to Google Maps is not explained. The description says it is a medication reminder, so the Maps key might be for a pharmacy locator or a map of nearby drugstores, but the README does not say. This is a case where the missing key is a barrier and a signal that the app has features beyond the core reminder.

Maintenance and License Considerations

The repository is not archived, but the last push is unknown and there are no recent releases. That is a red flag for maintenance. The README is written in a casual tone with a promotional line about the project's effect on learning, but it does not include a changelog, a contribution guide, or a code of conduct. The license is MIT, which means you can use, modify, and distribute the code with attribution, but you are responsible for your own use, especially the Google Maps key and any dependencies. The MIT license does not grant trademark rights, and the app name Healsense might be a trademark. The lack of release tags means you cannot easily track version changes or pin dependencies. For a production app, this is risky. You would need to fork the repository and maintain it yourself if you adopt it.

Alternatives and When Healsense Is the Wrong Tool

A real alternative to Healsense is the open-source projectMediTrack, which uses a simpler MVVM architecture with provider for state management and a single SQLite database via sqflite. The difference in approach is significant: MediTrack does not enforce DDD layers or service locator, so it is easier to follow for beginners but harder to scale. Another alternative is the Flutter official samples for state management, which are smaller and focus on one concept. Healsense is the wrong tool if you need a minimal reminder app quickly, because its layered architecture and code generation add complexity without immediate benefit. It is also the wrong tool if you cannot afford a Google Maps API key or if you want to avoid external services. The right use case is learning how DDD, Drift, and Riverpod fit together in a real app, and then adapting those patterns to your own project.

Editorial conclusion

Adopt Healsense if you are a Flutter developer who wants a concrete, layered example of DDD with Drift, Riverpod, and service locator, and you are willing to supply your own GOOGLE_MAPS_API_KEY and fill in documentation gaps. Do not adopt it if you need a production-ready medication reminder without modification, because the repository lacks release tags, detailed setup steps, and evidence of ongoing maintenance. Before using it, verify the .env file handling, confirm the Google Maps key requirement is acceptable, and check whether the app still builds with the current Flutter and Dart versions. Then decide if the architectural patterns outweigh the missing operational details.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository