Tuesday, December 22, 2009

Recurring patterns in applications

I was just doodling around the architecture of my latest project when I suddenly realize that I have done the same thing over and over again for every project. I'm sure anyone of you who has successfully delivered more than ,say ,5 projects would realize that there is a pattern to almost 80-90% of stuff out there.

I started to scribble some of the recurring patterns I have seen again and again in many projects. I'm putting it here and am very greatful if anyone could add more to this. Now to verify what I'm saying is in fact recurring, I'm going to examine the presense of these patterns in three different context a) A social network ala facebook b) A workflow application c) A content management system (CMS)

1) All system must have Users

a) Social network : Yes
b) Workflow app: Yes
c) CMS: Yes

2) Users live in a Context (for example, roles, location etc.)
a) Social network: Yes. Two very obvious context: logged in logged out.
b) Workflow app: Definately yes. Swimlanes (roles) can be considered context
c) CMS: Yes. There are plain old users, there are admins, there uploaders, there are downloaders etc.

3) Given a User and a Context, there are a few Lists of Items.
a) Social network: YES. When you log in to facebook or twitter there is a list of entries/microblog
b) Workflow app: YES, you would have a list of tasks (either done, pending, kiv, delegated etc.
etc.)
c) CMS: YES. You would have a list of contents

4) An Item can contain either basic data: texts, numbers, links, images, videos, file attachments or links to other Items
a) Social network: Yes. You have all the classic types of data but also replies and "retwitts" etc.
b) Workflow app: Yes, you would have tasks descriptions and attachments for example. If the item is delegated, you will also see the delegated items
c) CMS: Yes. You will see the content and if you have "folders", you can have links to other data.

5) An item is aware of whom (Users) and how (Contexts) it should be accessed
a) Social network: Yes, only users and probably their friends could access certain photos for example
b) Workflow app: It is obvious with swimlanes, certain users canonly access certain data. What is more interesting is that certain users can access part of an item while others can only access other parts (think of government forms where you have "For Office Use Only" part)
c) CMS: Yes, folders have rights much like a Unix file system.

6) A User could be in a Relationship with N other Users. We call this relationship Contact.
a) Social network: Yes, obviously
b) Workflow app: Yes. In most workflow applications I've seen, Contacts are amed 'Supervisors', 'Subordinate' or 'Team member'.
c) CMS: You can certainly share content with other people. Not formally a Contact but still uses the same principles.

7) User should be able to log in to the system and eventually log out
a,b,c) Yes, obviously

8) A user can create Item and make it accessible to other Users (either from within his Contact or not)
a,b,c) Yes, obviously. This puts the responsibility of creating an Item on the User's hand.

9) User who creates an Item is responsible for the lifecycle (CRUD) of that Item
a,b,c) Yes, obviously

10) User who has access to an Item should be able to Read and optionally Update an Item
a,b,c) Yes, obviously

11) A system should be able to listen to the lifecycle of Items. User defined filters could be defined at each lifecycle action.
a) Social network: Yes. This is similar to Facebook email alerts when people reply to your post. The reply can be considered an Item, creating a reply is an event listened to by the system.
b) Workflow app: Yes. At every stage of a workflow, a filter can be triggered (I think Adempiere works this way to update its account database).
c) CMS: Yes. Again, email alerts can be sent when items are uploaded/created/deleted

12) There are 2 types of lifecycle action 1) Rules: To validate the lifecycle action
a) Social network: Yes. An email alert should only be sent if the new item created is a response to an existing item.
b) Workflow app: Yes. A rule is always attached to every "decision path" (the exclusive choice pattern) in a workflow.
c) CMS: Yes. A rule for example that states when a non-empty forlder cannot be deleted. Or a content viewed by another user cannot be deleted.

13) Type 2) Events that could trigger lifecycle actions on other objects.
a) Social network: Yes, adding a Contact (I.E. adding another person into your Contact) triggers an event that will add you to the contact of that other person. (I add u as friend implies, you will also add me as a friend).
b) Workflow app: Yes, for example in Adempiere, a workflow that creates an Invoice triggers the modification of Account.
c) CMS: Yes. Recursively deleting a non empty forlder might delete all its contents.

14) Users can do CRUD lifecycle on their Contacts. These actions will also generate Events.
a,b,c) Yes, obviously. You can always delete and add new people to your contact.


Now why are these patterns important? Well imagine now I've created a bare bone application (call it a framework if you will) and imagine that I want to create a Social Network. All I have to do is customised that "framework" and within a short time, tada~ a social network. I have only to define what is Item in my application context (which is social network), what is a User, what Events need to be generated and what Rules need to be triggred and I'm done. Someone else might define Items as Account, Activity, Invoice, Inventory etc. They might define Events as CreditToAccount and DebitFromAccount etc. and define Rules such as "When Inventory is low, start Procument process" and bam!, the framework is now an ERP.

Now let us take this further, what if this framework define not just bare bone stuff but also things like open persistence policy (which allows you to connect your app to any database), a well thought out GUI, a caching mechanism out of the box, a clustering facility , a reporting and BI facility and some security enhancement here and there. Suddenly, I can focus on creating my latest shiny new social network or create my own ERP focusing mainly on what the application should do rather than all the nitty gritty stuff like scalability.

Of course, what is defined here is probably incomplete at best and naive at worst. There are overlaps I'm sure (like Rules and Context could be the same thing). If you do have other stuff to add, please do enlighten me. (Or if you think certain things are just superflous). Maybe creating this framework could be my next big FOSS project :)

8 comments:

Raja Iskandar Shah said...

some other repeated stuff that is a must have for an application framework (this is what we are also trying to do with our own ida application framework)
1. navigation menu
2. permission
3. access logging
4. module manager (which controls which modules are active/inactive and upgrading of modules)
5. taxonomy (a way to categorise stuff)

Raja Iskandar Shah said...

ooppss. almost forgot
6. searching (a long long time ago i created a search function that is reused by all forms)

Azrul said...

Thanks for the feedback.

1) Navigation menu is a good suggestion
2) Permission can be done using Context or Rules
3) Logging: Another good suggestion. I was just thinking of adding that
4) I like the idea of automated admin interface ala django
5) Another good idea
6) This is in the pipeline, along with automated scalability, security etc.

All and all, good suggestions.

Unknown said...

look like you looking for magic. the closes you can find is appfuse, but still many things u cant do with it and required customize.

Azrul said...

Hi cometta,

Well, I'm not looking for magic, I'm just wondering what is the closes we ca get to "magic" without making things difficult to customise

Anonymous said...
This comment has been removed by a blog administrator.
Raja Iskandar Shah said...

here are another two recurring stuff
7. page not found
8. you do not have permission to access

these two would go into the details, but good to have it early in the development phase

Redhuan D. Oon said...

what u described is already existing out there. Some names that come to mind are OfBiz, LifeRay, ADempiere/Compiere family, etc. What you need to do is to stick to one such framework and fill in the missing gaps. One drawback though is the steep learning curve in such apps for your own team. You may be fast but its no one man show when are doing a huge project.

In not reinventing the wheel means u have to keep searching the net for that holy grail. Yesterday i just found one (i think) when i was investigating the latest scene on OSGI plugin advantage: http://wiki.eclipse.org/Toast