For the project I'm working on I was thinking to create a Java Module for each layer of my system:
servlet-presentation
defines the implementation of the presentation layer. It is composed by Java Servlets that call the layer below and by JSPs that represent the view (Also JS, CSS...)business
represents the service classes of the application, that contains the business logic.entity-api
represents the entity classes and the interfaces for their repositories, to isolate thebusiness
module from infrastructure code.entity-hibernate
represents an implementation ofentity-api
This is a simple approach that should do the trick for what I want to achieve: modularity for the presentation and persistence layer. (I may choose to add resteasy-presentation
one day, or entity-eclipselink
one day)
However, I'd also like a way to vertically partition the elements that compose my system for communication purposes. For this reason I wanted to use the plain old Java packages: classes in different layers that may adhere to the same use cases should be put in the same package. However, different Java Modules cannot have a package of the same name. What could be a way to achieve optimally split my codebase?
1 Answer 1
Slicing projects based on presentation, business and persistence is a very popular way of structuring a project. It is also a pretty costly one.
This is the kind of architecture where you try to implement or fix some feature, you'll likely have to work in multiple "modules" simultaneously. In other words, changes rarely will be localized. For new features probably never, because you'll almost certainly need all of those "layers".
Unless you have very specific architecture constraints, like multiple 3rd party (i.e. completely unknown) clients, or you're building a library for others to use, this kind of architecture will hurt you a lot long term.
Use your "vertical" packages to contain everything. Every aspect of the vertical slice, including UI and persistence. Try to keep everything about a feature localized.
This is may of course vary based on requirements and constraints, but it's an alternative nonetheless.
-
Took me a bit of searching to get the buzzword, but basically you are advocating for vertical slice architecture?Greg Burghardt– Greg Burghardt03/01/2022 20:51:11Commented Mar 1, 2022 at 20:51
-
Thank you a lot. I'll definitely bear your answer (And the article you linked) in mind. I must say it's indeed better (requirements-wise) to represent the codebase in terms of functionalitycidra– cidra03/01/2022 21:30:48Commented Mar 1, 2022 at 21:30
-
@GregBurghardt I just used the terminology from the OP. I hesitate to commit myself to a definition from somebody else. After reading up on it, scrolling through some youtube videos, I'm not entirely sure they're saying the same thing. They do have a point about Onion Architecture not being very maintainable though for average requirements.Robert Bräutigam– Robert Bräutigam03/02/2022 10:51:06Commented Mar 2, 2022 at 10:51