Falar: one product, three architectures

Why one product, three times

The desktop app owns the reference implementation: an event-sourced learning domain that persists every review and mistake rather than overwriting state. That domain model — what a review session is, how mastery is scored — is the thing being reused, not the code. The mobile client and the backend service each re-express those same rules under a different set of constraints: a backend that exposes them over GraphQL instead of an in-process call, and a mobile client that consumes them the same way any external client would, defaulting to fake data until the real backend is reachable.

The architecture is deliberately not identical across the three. Desktop event-sources because a learning domain's history has real value. The backend persists current state directly and skips event sourcing, because a GraphQL API answering "what is true right now" doesn't need a replayable log. Same author, same instinct toward separated layers, calibrated to what each piece actually needs — not reused wholesale because it worked once.