Architecture for a scoring and commentary apps

Question

About the app: This is an android app. The app has two components/ two different users, scorers who score the game and fans who view commentary of the game.

1. Scoring User : A scorer watches a live baseball game and puts the score after each pitch/event of the game. These events are pushed to the server and also stored locally in the scorer's phone.
2. Fans User : Fans who want to follow the game can view play-by-play/pitch-by-pitch commentary of the game on the fans app sent by the server based on the events sent by the scoring app.

Each game will have set of data associated with the game. Fixed data which wont change through out the game, like -:

1. Teams Name
2. Players List
3. Grounds Name .. ETC

Each match will also have a list/array of events. Each event will contain a number of information.

1. Batter Name
2. Pitcher Name
3. Runs scored
4. If wicket taken, how was the wicket taken. .. ETC

These list of events generated in each games are stored on the server. Over a period of time these events per match generate interesting insights about pitcher. Example : how is a pitcher better against left hand batters, how a batsman has better average when team win, etc.

Problems/Suggestions required :

1. The scorer might have made a mistake in scoring an event and needs to undo the last event. Which design pattern to use in android to support this?
2. Should the events be stored as JSON or POJOs on the android app? After each event on the scoring app the event needs to be stored on the local db and on the server. The data is sent to the server a JSON and dumped in a mongoDb.
3. The app needs to store details about each event to display in on the commentary app, also to generate insights. The scorer UI also shows the current batsman, runs scored by current batsman, total, current pitcher info etc. This keeps changing after every event. All these data can be derived and updated on the UI by two ways:
   1. Events list is updated after new event and all other derivable data is calculated again by looping the events. So in case of UNDO last event is removed and looping over again would recalculate actual values. This could keep the data accurate and less prone to errors but needs to traverse a long list each time.
   2. Along with events list there is another data structure that holds values for other info to be displayed on the UI. Events list is updated after new event and all other derivable data is also updated on the other data structure. This could cause mismatch in data cause data is duplicated, but you don't need to traverse the long list of events each time.

I have spent sometime on design patterns but could not take a decision on what to proceed with. An expert opinion/direction or a word from someone who has done something in similar lines would be very helpful.

Answer 1

An architecture is more then a pile of patterns. It's much more a set of principles followed in a cohesive way that avoids painting development into a corner. Religious zeal is not your friend here. Pragmatically avoiding misapplications is.

You mention undo which makes me think of the Command Pattern. The rub with this is every command the user could use has to also have undo code that undoes whatever the command did.

However, you also mention that you're willing to recalculate state from scratch on an undo. That means you could go the immutable route. Rather then ever change an event you simply recalculate state from all the events that haven't been undone. The rub here is performance. An undo can become traumatic. However, this can be mitigated by saving previous state to replay a shorter list of events onto. How often you save state is a tuning variable you use to adjust your space-time tradeoff performance.