The problem
A score tells you what happened, but not necessarily why. Useful bowling history needs to preserve enough context to compare performance across balls, alleys, patterns, leagues, tournaments, practice sessions, and time—while still allowing fast entry during play.
Domain decisions that matter
- Derived statistics are computed from source events rather than stored beside them and allowed to drift.
- Completed competitive/practice games feed analytics; social sessions can remain in history without contaminating performance metrics.
- Ball attribution lives at the delivery level so equipment analysis has evidence behind it.
- Retired equipment is preserved rather than deleted, because historical sessions still need to explain themselves.
- “House pattern” is treated as a grouping, not invented as a fake oil-pattern entity.
- An offline local store and later synchronization support the real environment: bowling centers do not always have reliable connectivity.
A focused product can still become deep
Narrow scope does not mean shallow behavior. Once the core session model is sound, drills, leave conversion, ball maintenance, trend analysis, league detail, and equipment recommendations can grow from the same evidence without turning the app into a generic sports platform.
Why it stays private
The repository is not needed to demonstrate the product judgment. A public-safe case study can show the domain model, rules, offline strategy, and analytics philosophy while personal performance records and user-specific data remain private.