Should layers be visualized in the code structure?
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
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:
- Developers often introduce dependencies between classes that were never intended, but they are introduced because you could do it.
- If everything is
publicthe IDE can not support you well. Developers ususally use some kind of auto-completion or they use type searches when writing code. If everything ispublic, 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. Thuspublicdoesn'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.
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:
- Modular Monoliths, Simon Brown, GOTO 2018
- Separation of api and implementation, René Link, Feb. 2012
- Handling Multiple Actors in a Use Case in Clean Architecture and DDD
- Where should I put uploaded files on a Clean Architecture project?
- Clean architecture: inverting dependency of EF DbContext
- How to make a migration to an existing Postgresql database?
- StateFlow not getting collected as expected
- return multiple times from single function using kotlin co routines
- Mvvm with clean architecture, how to handle events in MAUI?
- How to register Infrastructure layer dependencies in Clean Architecture using .NET 6?
- What's the point of creating mappers to convert entity<>DTOs?
- How do I have a method return one of almost the same classes case to case?
- NestJS provider undefined I can't find the reason
- Internet check stream in a Flutter app with clean architecture and Cubit?
- Approach to Handling Plugin and Package Dependencies in Clean Architecture Data Sources?
- Global access to authorization token in Flutter Clean Architecture
- Gateway in Interface Adapter Layer of Clean Architect
- In clean architecture, is the presentation layer allowed to communicate directly with the infrastructure layer?
- Flutter Clean Architecture communication between Use Cases and Blocs
- Need clarification on the AuditableEntityInterceptor class of the Clean Architecture solution template for C#
- How Can I Integrate Dagger in the Domain Layer and Hilt in the App and Data Layers of an Android Application following CLEAN architecture principles?
- What are reciprocal polymorphic boundary interfaces?
- MVVM and clean architecture both are same in flutter?
- Flutter way to implement clean architecture
- Which approach is better for passing ETags to input ports: as domain objects or as strings?
- Difference between REP(Reuse/Release Equivalence Principle) and CRP (Common Reuse Principle)
- Service in clean architecture
- Where should I place the logic for one entity altering the state of another entity within Django REST Framework?
- Clean Architecture with paging3 and compose passing PagingData to domain layer
- how to stream or fetch data periodically using bloc?
- Advice to refactor null checks?
- Flutter Clean Architecture