Software Developing: Studying The Bliki Domain Model

Software Developing: Studying The Bliki Domain Model

The bliki concept has always been interesting. Merging the capabilities of a wiki platform with a blogging platform is a breakthrough because it allows a user to create various content that may or may not be a blog entry in a rather simple way. This isn't a new concept, according to Martin Fowler it's around since 2003(information from wikipedia), although it's not a widely used piece of software. Nowadays it's very usual to use blogging software or wiki software, but somehow the fusion between those two types of software seems to be forgotten by the general user.

When I started using SnipSnap and later developing code for it, not only my interest for blikis grew but also, allowed me to understand and put in practice the concepts that exist in this kind of software. SnipSnap isn't complete or perfect but learning how it works was a pleasant and instructive experience.

Lately, I've been looking into other blikis software in order to understand what is really the business logic and the underlying model. This post summons up the ideas and model I've thought.

This time example code isn't being provided, because it doesn't exist. The ideas below are purely conceptual and there is currently no source code implementing them. In my opinion, it seems a good model, but different people have different views from the problem so the objective of this post is to create discussion regarding the topic.

I've broken down the model into three parts, they are the Entry Model, the Meta Data Model and the Access Control Model. I'll be addressing separately to each one of them.
Readers should pay attention that some relations are only interesting in one of the models, so in order to save visual space those relations won't be represented in the other two models, but that doesn't mean it's not there.

The models below were designed with a domain driven design philosophy, anyone interested in learning more about such kind of architecture may read the following posts:

• Software Developing: Domain Driven Design
• Software Developing: More About Domain Driven Design
• Software Developing: Domain Driven Design, looking at Persistence

Let's now start with the entry model.

The Entry Model

This part of the model is the actual bliki's core. The Entry entity represents nothing more than information inserted by the User. In this kind of software three different types of entries were identified, they are:

• Wiki Page
• Post
• Comment

The names are self explanatory, but that doesn't explain the logic that each one of this kind of entries contains.
For example, in my opinion, a Wiki Page has to support sub pages (not to mention history). The sub page concept should be understand as wiki pages children that create a page hierarchy. Also, I believe that any type of entry must allow - if permitted by the access control, of course - comments.
Some readers might be asking why isn't Blog listed as an entry. That happens because, a blog is nothing more than a container of Posts, it's not information inserted by the user but rather something that knows how to display some specific information.

But let's see in a more detailed manner the domain regarding the Entry Model that can be seen on the right.

The Entry entity has three sub-classes which are the types previously mentioned. Entries can contain other entries, which is the way to preserved the historic of entries. During implementation certain verifications need to be part of the business logic in order to only allow entries that are historic to be added in this relation. There's also another interesting relation in the Entry entity, any type of Entry allows comments, notice that this allows for comments to contain comments. At first this mind sound confusing, but it's actually the representation of a message thread.

Besides that, an Entry has an owner, which is a registered User within the bliki and an entity that represents all it's meta data called Meta Entry. We'll talk more about this last entity soon.

Regarding the Blog entity, like has been said it's not an Entry but a container of Posts. It also contains a list of editors, which are registered Users.

Finally there's the Wiki Page entity. This entity also uses the Composite Design Pattern allowing an hierarchy of pages. This entity can also be more specific such as a Wiki User Page, which is directly connected to the User or a Groovy Script Page.
A Groovy Script Page would contain Groovy code - more about Groovy in Java Programming: Getting your code spicy with Groovy - that would be executed at runtime. Although it sounds a shiny feature it's probably useless and it doesn't really need to exist in the model, that is why it was chosen to be represented with dashed lines.

The main ideas used when creating this part of model were the following:

1. There are three different kinds of entries;
2. Every entry has an owner;
3. Every entry can be commented;
4. It's good to have message threads support in the model;
5. Every entry has historic;
6. Every entry has meta data;
7. Wiki Pages have to allow hierarchy;
8. Wiki Pages may be extended for more specific behaviour such as pages for bliki's users.

Meta Data Model

From the three, this is probably the simplest model. The idea of this model is to understand what is the Entry's meta data and how it should be placed in the model. The Meta Data entities identified were the following (although there may be more):

• Backlink or Referee
• TrackBack (read more about TrackBack)
• Attachment
• Tag

The Meta Entry entity exists because if this meta data entities were directly connected to the Entry when a new version would be created the meta-information would have be copied (not actually copied since it was only references moving around). The problem with that - besides information not being centralised - would be the duplication of meta information creating strange scenarios.

For example, imagine a certain Tag T1 connected to an Entry E. After edition of E, there would be E and E', if the Tag was directly connected to the Entry both E and E' would be tagged with T1, that means T1 would have two entries but they were actually the same entry but in different versions!

Also, upon the presentation of the Access Control Model we'll see that there is once again the need to have an entity that represents not only the current version of the Entry but also all its historic.

Even though meta data entities have been presented, it wasn't yet explained what is a meta data entity. An Entry object regarding the information it holds contains a limited set of explicit - somehow directly inserted into the system - and implicit - in a way the system infers it - of information regarding the entry but without actually being the information it holds, hence called meta information or meta data.

Other examples of meta data can be the number of views a certain entry had, the number of editions, among other parameters that themselves can be part of the actual Meta Entry and do not need to be represented by an entity.

Regarding the guide lines that were used when creating this part, there was only one the Meta Model must be transversal to the Entry historic.

Access Control Model

This part of the model defines the access control for the bliki's CRUD operations. The access control is defined through rules, which have been limited to three different types:

• User Rules
• Group Rules
• Role Rules

Each one of this kind of rules contains a tuple. One is the operation, the other is the User, Group or Role according to the access rule type.

Like it can be seen in the model on the right a Group is nothing more than an aggregation of Users. Also, since a certain User should be able to be in more than one group the relation between both entities is many to many.

Another concept introduced with the Access Control Model is the Role. Every User has a set of roles. Examples of roles in this sort of applications may be, for example, admin, editor, blogger among others.
Defining access control using roles can be seen has defining access control for groups where the groups are defined by the system instead of the User.

The current model does not support composition of rules but that may be an interesting feature to add.

The main concerns when creating this part of the model were:

1. The entry access control is transversal to the historic
2. It should be able to define access control for a given user, group of users or a role
3. The operations that are submitted to access control can be reduced to CRUD operations

Final Thoughts

By no means this model is being presented as the model. This is only a result found for the question "how is a bliki domain model?". It's not perfect, it may be flawed or have things missing. It actually should be seen as a first draft and it's totally open for discussions about the subject.

Even thought while writing this post there was the effort to see all the blikis that exist in order to summon up the knowledge that each piece of software contributes it's impossible to be sure that everything was seen - most likely it wasn't - and nothing was overlooked - most likely there are things overlooked. Once again discussion about the subject is probably the best thing to be done.

I'm also providing the complete model image for anyone interested.

Finally, I suggest the reading of the wikipedia blikis page.

Hope it was an interesting reading.