Should layers be visualized in the code structure?

user_17476302 0
Viewed 152

After have read Clean Architecture by Uncle Bob i have been thinking about the concept of screaming architecture and the last chapter around organizing code.

I have generally liked working with layers being present in the structure to easily place code in the correct layer but I also see a benefit in dividing by feature.

A large project I recently started working on does not present the layer structure at all and you have to look at an architecture document to see in what layer the java package resides. The project uses OSGI bundles.

This project is worked on successfully by a large amount of developers and seems to work well but I can't help feeling that the structure is confusing and hard to work with and the architect needs to be involved when creating new features to make sure layers are adhered to.

My question is if this is common and what the reason would be to not include the layer structure in some way?

For instance doing something like this seems like a clean solution. https://blog.ttulka.com/package-by-component-with-clean-modules-in-java

clean-architecture code-structure
1 Answers

My question is if this is common and what the reason would be to not include the layer structure in some way?

The question is "Does the structure of the code give you any benefit?" and this depends on the programming language you use.

In Java, for example, you have the access modifiers public, protected, private and default (no modifier). The default and the protected allows access within the same package. The protected also allows access in extended classes elsewhere. This means that if you make use of this modifiers you can control the visibility of classes, methods and fields.

Controlling access to classes and class members can make your life a lot easier. I often see that the public modifier is extensively used. This leads to some problems:

  1. Developers often introduce dependencies between classes that were never intended, but they are introduced because you could do it.
  2. If everything is public the IDE can not support you well. Developers ususally use some kind of auto-completion or they use type searches when writing code. If everything is public, then everything can be accessed from everywhere. Since the IDE will list you all accsessible options, it will show you a long list of entries. Thus public doesn't make life easier. It's also sad but true that as a result of this developers often introduce more packages to organize the code and therefore make it worse by thinking they make it better.

Simon Brown, who wrote the chapter "The missing chapter" in the clean architecture book, says:

The access modifiers in Java are not perfect, but ignoring them is just asking for trouble. The way Java types are placed into packaged can actually make a huge difference to how accessible (or inaccessible) those types can be when Java's access modifiers are applied appropriately. If I bring packages back and mark (by graphically fading) those types where the access modifier can be made more restrictive, the picture becomes pretty interresting.

Figure 34.8, the missing chapter, clean architecture book

The diagram is taken from the clean architecture book, chapter "the missing chapter", page 318.

Now you can see the differences between the packaging types. If everything is public they are all effectively equal.

More information can be found here:

user_9741860
Related