1

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 the business module from infrastructure code.
  • entity-hibernate represents an implementation of entity-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?

Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
3
  • Took me a bit of searching to get the buzzword, but basically you are advocating for vertical slice architecture? Commented 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 functionality Commented 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. Commented Mar 2, 2022 at 10:51

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.