Porting fmodel to Dart

A while ago I watched Jérémie Chassaing’s lecture about functional domain modelling.

It was beautiful.

The Fraktalio team (Ivan Dugalic) did an amazing job and brought those ideas to Kotlin, Rust, and TypeScript.

For a while I’ve been a fan of the Dart programming language. Why? It’s a bliss to work with:

• Easy to pick up — if you know Java, TypeScript, C#, Objective-C, C++, or C, you can more or less start writing Dart right away;
• Strong static typing;
• Null safety;
• All you need is the dart command-line tool — it supports testing, analysis, compilation, and publishing, with both JIT and AOT compilation options;
  • no Gradle, no IntelliJ IDEA, and little other heavyweight tooling required;
• Hot reload during development (especially with Flutter) means you do not have to wait for a full compile cycle to see whether your change works;
• The Dart team added the dart mcp-server command, which makes it much easier to work with AI agents;
• It is battle-tested in production: customer-facing Google products such as AdWords and AdSense use AngularDart; other Google teams also ship Dart in production (see dart.dev);
• The Flutter framework is built on Dart and lets you target iOS, Android, Linux, Windows, macOS, and the web (including WebAssembly) from one codebase;

Why port fmodel to Dart?

Long story short: I decided to port fmodel to Dart so I can use event modeling, event sourcing, and CQRS with Dart and Flutter.

The current version is 0.1.0-dev.1. I believe I have ported everything correctly, but for now it is a dev-preview release. The application layer is still marked experimental while the port is aligned with the Kotlin semantics and the TypeScript public API shape.

Why port fmodel at all?

LLMs are non-deterministic, so if you use them to write code — as many people do nowadays — you need to tackle that non-determinism. How?

1. A clear requirements specification helps (event modeling spec, ESDM, or system requirements specifications from systems engineering)
2. Test-driven development helps
3. A null-safe language helps
4. A strongly statically typed language helps

Rust is a good language for LLM-based development, I think: the Rust compiler “fights” the LLM and prevents many classes of bugs.

Dart is not as strict as Rust, and it is garbage-collected, so there is no manual memory management as in Rust — but it has Flutter.

There is always a tradeoff.

Links

• Repository: github.com/dclimber/fmodel_dart
• Pub package: pub.dev/packages/fmodel
• Example with Jaspr and SQLite as an event store for the order management system: github.com/dclimber/order-management-demo-dart

But you’re a Python developer!

Yes — I know Python, and it is the language I get paid to work in.

If I started getting paid to write event-sourced systems in Dart (Kotlin, Rust, and even TypeScript on Deno would also be fine), I’d be quite happy.

Although I already have good use for Dart and fmodel-dart in some plans of my own…

The future looks bright :)