Flapper: discovering the domain before splitting the monolith

Context

At Flapper, the core product was a PHP monolith over seven years old, with little useful documentation and without the developers who had created it. The application sustained the executive aviation operation and could not be stopped for a rewrite.

Constraints

Code and database accumulated rules and dependencies that were hard to explain. Changes had unpredictable side effects, and there were no remaining specialists to confirm how each part of the system should evolve. Migration had to coexist with the product in production.

Problem

Switching PHP for another technology would not answer the main question: which rules belonged together and which dependencies could be separated without breaking operations. The system needed domain boundaries before new services.

Decision

I used the existing database and code as a discovery source. Table groupings and relationships helped identify bounded contexts; from there, migration followed the Strangler pattern:

1. extract one domain at a time, without stopping the monolith;
2. keep in each context only the local representation of the data it needed;
3. propagate changes through Kafka events, instead of connecting every service to the old database;
4. use Node.js, NestJS, and Go in the first modules, with gRPC, REST, or GraphQL depending on the consumer;
5. document the strategy and the first modules so the team could continue the transformation.

Discarded alternative

Rewriting the whole monolith, or keeping new services tied to the same database and shared relationships. The first option would stop the business; the second would preserve the coupling the migration needed to reduce.

Result

The domain-based split reduced the table count by approximately 25% and created seven databases organized by context. The people, authentication, and aircraft modules were the first steps of a transformation planned to continue beyond the initial delivery.

Limitations

The number measures the table reduction in that domain split, not financial gain, the complete migration, or a market result for the company. The experience end date diverges across older sources; the published period follows the exported profile. If a domain still depends on rules unmapped in the monolith, its extraction must be postponed or given an explicit transitional integration.