2

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

CEH
  • 29
  • 5

1 Answers1

1

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:

René Link
  • 48,224
  • 13
  • 108
  • 140
  • Perhaps I was a bit unclear in my question. It was more related to the readability of the code and making sure that it is clear for the developers where to place their code so that for instance infrastructure code does not get put into the domain or the other way around. Of course this is possible even with clear layer names in the structure but it at least gives the developer knowledge about in what layer he is working. – CEH Jan 14 '22 at 07:13
  • @CEH You can use class name suffixes like `CustomerDO` (DomainObject) or sub-packages `com.acme.shop.order.entities`, `com.acme.shop.order.usecases` or `com.acme.shop.order.gateways`. Maybe you make use of a [Layer Supertype](https://www.martinfowler.com/eaaCatalog/layerSupertype.html). Finally I guess that no matter what you do, developers can always put code in the wrong place. Thus I would go for code and architecture reviews. – René Link Jan 14 '22 at 13:52
  • I found some time and watched the Modular Monoliths presentation and that clarifies a lot for me. I especially found the part in the end useful when he talks about using maven or gradle modules to help divide the code which matches the link I shared. Of course what you use depends on the project but I think this structure is quite good for ensuring architecture rules are followed. As I understand this does not work well with OSGI though. – CEH Jan 15 '22 at 13:58