develop with

Use Seamonkeys as architecture case study

Non-proprietary case study to evaluate architectural concepts

Seamonkey Case Study

The purpose of this page is to illustrate a business requirement around the building of a virtual seamonkey platform. The idea is to use this to evaluate architecture changes and framework concepts based on the requirements below.

##Business objective## Be the best virtual seamonkey experience available in the world.

##Business requirements##


Users should be able to register for the experience. Detail requirements

When a user is registered, the user can authenticate or reset their password. (TODO Detail)


Authenticated users can create, update and share Seamonkey’s. When registered a user has its own tank to manage their sea monkey experience.

They will be able to create a seamonkey by adding it to their tank. When added a seamonkey starts a life cycle based on amount of algae provided in the tank. The tank accumulates algae in the following ways: Seamonkey waste Algae tablets added by user, tablets at 20 units of algae Water aging process with air in tank

The lifecyle of a seamonkey is: * Baby - lives off 1 unit of algae, does not produce algae. Dies if tank is over 20 algae units * Youth - lives off 10 units of algae, produces 2-3 units of algae * Adult - lives off 8 units of algae, produces 4 units of algae

A seamonkey when added should be named.

Each seamonkey is assigned a personality when added and named. The personality type will determine the personal notifications the user gets as well as how fast or slow they grow. In addition, depending on the personality types in a tank the mixture may create personal conflict a alerts for the user. The user may need to share the monkey with another user to get it out of their tank.


Seamonkey’s can be shared with other users in a network. When a user share s a seamonkey they are sending the monkey to the other users tank.

A tank is created if the user doesn’t have one. The user must know the other users email address.


There are a couple different types of notifications: * Lifecycle events - when a seamonkey has grown, the tank alerts on maintenance, etc… * Personality / nanny messages - notifications that involve personality based messages, ie “sam was swimming today and did a backflip” * Social messages - notifications of seamonkey being shared / returned or a nanny event that happened on another users tank with the users seamonkey

The user will get notifications for different reasons as stated above. These notifications should support both mobile, email and in-app realtime alerts. The user should be able to set the preferences on which alert they get.

Seamonkey changes and notifications can also be received by external applications such as campfire, etc…

Technology Requirements

The platform must support: * third-party integration for event changes of sea-monkeys * user should be able to add a third-party integration * notifications should be near-realtime

comments powered by Disqus

Want to see a topic covered? create a suggestion

Get more developer references and books in the developwith store.

List of how tos for architecture