Replacing packages with tags

How can we use tags, and a tagarchy, in Java, if Java is so package oriented? The solution is to map the tagarchy onto the package hierarchy, much in the same way as persistence layers try to map objects into database tables. Unfortunately, just as there is an object-relational impedance mismatch, there will be a tag-package impedance mismatch too, but tools can help to make this impedance mismatch transparent to the developers that want to use a tagarchy rather than a hierarchy.

Here's a practical way to map tags to packages:

1. For each class, order its tags alphabetically, and concatenate them with a dot («.») inbetween each tag.
2. Prefix the result from the first step with what would otherwise be the top level package name.

To make things clear, here's an example. Suppose we have a class named RegisterOrderDialog. It is tagged with the tag order because it belongs to the order feature, and it is tagged with the tags ui and swing because it belongs to the SWING-based user interface. Ordering the three tags alphabetically results into order.swing.ui, which we'll prefix with the name com.acme.store, the company name and the project name. The package name for the class RegisterOrderDialog should therefore be com.acme.store.order.swing.ui.

The project will also contain classes tagged with e.g. ui and html for the web based user interface, and domain for the domain objects, and classes tagged with e.g. bill and admin for the billing feature and the administration feature. This may result in the following list of packages present in the project:

com.acme.store.admin.domain

com.acme.store.admin.html.ui

com.acme.store.admin.swing.ui

com.acme.store.bill.domain

com.acme.store.bill.html.ui

com.acme.store.bill.swing.ui

com.acme.store.domain.order

com.acme.store.html.order.ui

com.acme.store.order.swing.ui

Notice that in this example, most of the packages have the feature tag first, but there are two packages that have the layer tag first.

By feature or by layer? Neither and both!

It's one of those classical discussions that has been going on for years: should you organize your code by feature or by layer? What's the right answer to that question depends on the project and the way developers are going to work: will they have the need to look at the code from a layers' perspective, then the code should be organized by layer first. Will they use the features' perspective most of the time, then the code should be organized by feature first. But what if a group of developers will access the code by feature, and another group will access the code by layer most of the time? Or what if you would like to access the code by feature half of the time, and by layer the rest of the time? (Which is almost equal to saying that you really don't know.)

The problem may be that we're asking the wrong question. In stead of asking whether we're going to access the code by layer or by feature most of the time (or that we want to impose one of them on the developer team), we should be asking how we can allow the developers to access the code the way that suits them best at any time. Or in other words: if they need to access the code by layer now, and by feature for the next task, how can we accommodate for that? The answer is: by not organizing our code in a fixed, hierarchical manner, but by using tags and tools that allow to access the code by those tags. Unfortunately languages like Java don't support this yet, so we'll have to find a way around that...

Tagarchy

I define the concept of a tagarchy as an arrangement of objects, people, elements, values, grades, orders, classes, etc., by tags. This contrasts to a hierarchy, in which the structure of the arrangement implies a sort of ranking: the collection is first divided by the most important property, then by the second most important, and so on. This does not mean that a tagarchy is a sort of anarchy either, because each element in the collection has multiple tags associated to it, and these tags can be used to create an ad hoc hierarchy, and there are some strict rules on how each element in the collection should be tagged.

Tagarchies are used in many Web 2.0 applications, Delicious and Flickr being two of them.