APP & Data Model
app: VEIL
includeWebSession
User
ContentCabinet
Post
Friend
Tag
TimeLimitedEngagement
Meetup [Friend.friends]
Discovery [Post.posts, ContentCabinet.contentCabinets]
Design Reflection
- Concepts Refinement & Data Modelling
The relation between the concepts emerges during the design process of data modeling, which in turn consolidates the concepts. I have made made majors changes to the concepts design. For example, I have removed the "veil" concept and treat it as a behavior of the Contents Cabinet concept. And instead of mixing the Post concept with the Content Cabitnet concept, I have made them two separate concepts. This gives me the advantage of having a more clear and concise data model, which makes it easy to implement the "veil" behavior and the time-limited engagement behavior. Seperating the two concepts echoes with my design intention of allowing users to put all kinds of contents in their content cabinet, not just posts (imagine more content concepts such as Book, Album, Movie and etc.).
- Relation & Redundancy
The relations between concepts in the data model can get complicated. There's a fine balance to be acheived through carefully constructing the interfaces. For example, the relation between the Tag and the Post is a many-to-many, which is a bit tricky to implement. I have decided to use bidirectional many-to-many relation, which means that the Post has a list of Tags' id, and the Tag also has a list of Posts' id it tags. This is a bit redundant, but it makes the lookup process much easier, since the number of tags and posts one user has is not likely to be very large and there are high read demands.
There is also an arbitary dependency between two concepts. Take my Discovery and Post concepts as an example, it makes no sense if there's no Post in the first place, as then there's nothing to discover. Therefore, I make the Post.posts list a required field in the Discovery concept. In this case, we don't need to keep track of all the posts in each discovery, instead, we can keep a public reference to all the posts in the app, reducing unnecessary redundancy.
- Tradeoffs & Sychronization
Backend is not isolated. It also needs to cater to the app-level concern. Tradeoffs are made to support more intuitive and specific interfaces for the user. Initially, I wrote up the sychronization logic in the backend, such that whenever a user deletes a post and the post's tags will also be deleted if they are only tagged to this post. However, this is not ideal, since the user might want to reuse the tag for other posts or simply just look up all the tags he/she has. Therefore, I have decided to remove the sychronization and let the user handle it. In turn, this may add to the memory usage in the database, but it is a tradeoff I am willing to make.