Skip to content

Architecture Design

Julia Strout edited this page Oct 28, 2016 · 1 revision

Minus the Ionic 2 CRUD code, the most important classes and methods are laid out in the following UML diagram:

fantasydj_uml

Our model is broken down into five main objects. Users, Leagues, Playlists, and Songs are fairly straightforward as to their purposes. A SongStat will be a daily log entry of a song's popularity according to Spotify.

The two key libraries that very quickly clutter up the more procedurally-written original version of FantasyDJ are the ones for interfacing with external data sources: Firebase and Spotify. These will be encapsulated into their own generically-named packages: data and music. The data package is comprised of data access objects (DAOs) that hide the concept of Firebase from the rest of the application: you ask the LeagueDao for a League, and it takes care of marshaling the JSON returned from Firebase into a League object. The music package hides all of the impertinent information and strange query mechanisms introduced by the Spotify API and puts it behind a class called SpotifyQuerier, which has find...() methods, much like the DAOs have, that return result objects containing only the most useful information.

Finally, there is a service package, which for now contains a single but very important class: DailyMaintenanceService, which will update the song stats and playlist scores, determine league winners, and notify users of their standing. This class does not run on a phone but instead runs as a cron job on a server.

Clone this wiki locally