Architecture as tidying up

Unstructured picture
Unstructured picture

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.

Tidied picture
Tidied picture

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?

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in English, Java, Software Development. Bookmark the permalink.

7 Responses to Architecture as tidying up

  1. Filip van Laenen says:

    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?

  2. tfnico says:

    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.

  3. jenifier789 says:

    In ffice right now will go through this latter.

    Have a nice day
    leabs
    ______________________________________________
    aion gold | Cheap Aion kinah

  4. jenifier789 says:

    i added this to my collge report

    respect
    marshel
    ______________________________________________
    aion kinah | Cheap Aion kinah

  5. lepine kong says:

    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. 

  6. 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.

  7. tlheen says:

    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.

Comments are closed.