I recently started on a new project. Looking over the code base, I saw the familiar structure of many projects: Definitions of classes goes here, persistence logic goes over there, interfaces to the persistence logic goes this other place, code for transforming from one structure to another in yet another place and so on. This is common, neat, and unfortunate.
As an exercise to understand the architecture of this system, I decided to add some new functionality: Displaying some data to the user. I haven’t worked this task oriented with this sort of system before, and so I hadn’t noticed just how extremely clumsy the common structure of these projects is to work with. In order to create the functionality, I had to navigate to around 10 different directories. In each directory, I had to work with one single file, and ignore the tens of files around it with similar names.
While watching a few videos from the TED-conference, it finally struck me: We often think that the job of software architecture is to tidy things up, so that things with the same attributes are sorted into neat piles. Too often, the attribute that we chose as the basis for our organization is an incidental, inconsequential one.
Here’s how to tidy up art:
Maybe this is not how we should organize our software system? What do you think?
- The pictures are from Ursus Wehrli’s book Tidying up art. Be sure to check out his 15 minute talk from the TED-conference
- This subject was also discussed in my blog post on Packaging by features, rather than layer.
This is a good example of why we should start using tags instead of packages (directories) to organize our code. I bet that you could have accessed almost all if not all of those classes through one or two specific tags without being too much distracted by other classes if that had have been possible, right?
Good thought, Johannes. I was just struggling with this yesterday, I was adding a JDBC implementation of an interface inside a functional package “picture.storage” ,and suddenly I found myself having to increase the visibility of several implementation methods to public so I could use them in the “dao.jdbc” package. Very booring.
In ffice right now will go through this latter.
Have a nice day
leabs
______________________________________________
aion gold | Cheap Aion kinah
i added this to my collge report
respect
marshel
______________________________________________
aion kinah | Cheap Aion kinah
My thought is that software should apply fractal concept: why on earth can’t we have virtual packages like we can have virtual folders for an OS ? This would then give the possibility to have multiple perspectives on the SAME reality depending on the needs.Â
I think you may be suffering from organization-itis, Lepine. ;-) That being said, using an interface or annotation to mark something as a controller or repository is still a valid option. Especially with interfaces, it’s easy in most IDEs to list all implementations of the interface.
I have recently thought about packages and meta-data. With packages, you can only describe one thing at a time. Usually, either a functional/domain concept or a technical/type of class as you describe here.
At the same time we have different kinds of meta-data. E.g. interfaces and annotations as you have already mentioned, but also naming convention of classes. If we place all our services in a service-package, and at the same time we both mark the class as a @Service and give the class a *Service-name, we have told the same thing 3 times. It should be enough with one. We don’t have that many options for functional/domain concepts – this is another reason why I think we should use the package name more wisely and use it for functional/domain concepts instead of technical terms.