How to Structure Modern Enterprise Java Projects

Any Java developer sooner or later runs into the question of how to structure their projects. Especially in the enterprise world, there are countless examples of over-engineered project structures, with build modules, technical layering, complex packaging, and the like. In this video, I want to answer the question what I think an effective structure and approach looks like for modern, cloud-native Java projects.

We’ll have a look at build/JDK modules, technical versus horizontal layering, package structures, screaming architecture, Boundary Control Entity, and test project structures.

[higorgranzoto]

Hi Sebastian, I really like your content, just a feedback and a kindly request to don't help demonize architects, as you can influence a misconception of the role at 1:38 of this video. In my experience there is more developers requesting over-engineering structures than architects. They are the ones who pass the last few years trying to explain exactly what you are doing today at the same time that needs to carry the burden of been acuse to live in the Ivory Tower.

[estebanmurcia]

I've seen this domain driven structure and i wonder, what should i do if i need another domain? Say, for a store when the user is about to pay i might need the info if the user which would be on the user domain and also the shopping cart ( i think this could arguably be in the same domain but for this example let's pretend it's in a different domain) should i just import the needed classes from the payment domain?

[syncaccount]

Modules make sense to use. Cache optimization, code reusability, encapsulation, etc...

[EdwardNorthwind]

Hello.
What should I do if I need common interfaces/abstract parent classes for some packages?

[ranjithramachandran]

Interesting video, and it makes a nice point about horizontal vs vertical layers. I do not like the proposed project structure. Purely from maintenance or onboarding perspectives, a more "do n't-make-me-think" approach would be to stick with "controller/rest/web" for Controllers, "service" for business logic, and "repo/repository" for data access. Either of the structuring does not make much of a difference but I think it is better to stick with 'what is familiar' at least in this case.

[jonathanlyde]

Would you consider making a new video like this with focus on DDD? Or is there some other material you can recommend for Quarkus application using DDD.

[mklueh]

I believe there is one reason to use Gradle modules even if you just have one single application and you don't need module reusability: build time optimization through Gradle's caching mechanism. Not sure how big the impact is and at which project size it is worth the effort of introducing artificial boundaries

[uhlme]

I was a bit surprised that the graphical representation for horizontal and vertical layering looked the same.
Shouldn't vertical layering be represented like this:
| customers | orders | inventory |
?

[CarlosHenriqueBarbosa]

Great stuff! If I have to create one or two reusable class, should I left them in the same packages level?

[andreasbrey]

Grützi. It's entertaining, ty! The title is however misleading should be more in the direction of "recommendations" or "some aspects of" ... I like it, when you are getting passionate about architecture decisions even if it leads to slightly unjustified utterances. In really (!) big, distributed applications with 'components' that are not in your control some ideas might be rated differently. And personally: "Vertical layers" = what about helper functions, app functions and associated repos? How would you position one tiny quality aspect "Cache or offline abilitties"?

[WrldBraker]

Hey yo Sebastian! As always great knowledge sharing!)

I would like to know when it comes to the code level optimization, when you see that some artifacts share same functionality like dao and apis for communicating, for instance custom RF communication protocol which is required across certain applications, currently I handle this by creating library projects which are further included as maven dependies. Is this the right way to handle such cases? It just brings some pain while changing a lot of things simultaneously.

One more question if you can ))) How to handle UI? What if I want every deployment unit to have it own small UI to interact with? This can be a lot of raspberry devices that have display or access by web. I find it easy to manage and maintain when both functionality and ui are in the same project, does it make sense to have a separate project for UI?

Thank you! Have a wonderful day.

[vphilipnyc]

The concept is nice, but it would irk me that a controller isn't under the control directory. Also, another key benefit for the horizontal design is that you can compare classes to see what is missing or added between similar files. This has identified so many bugs personally. You might realize that you're missing a simple annotation or it may make certain interfaces more consistent because you are comparing classes side-by-side without hunting for them. It sometimes helps you identify similar but not exact duplicate code. Maybe you realize you can use a Java record because you used it similarly. If you're at the level where you're creating microservices and need to identify those layers, you're going to have some work and testing ahead of you anyway and that day may never happen especially for small or midsize projects. A design based on business functions is more subjective too. For example, I may want to create an ad layer, but then another developer may reasonably state there's only one class in the directory and it's not needed, or that it should be renamed. Now we have to deal with renaming a package. None of this advances the project.

[MortezaRezaei-wx]

It looks like you've never seen an enterprise project. you don't know what an enterprise project is. did you see a project with hundreds and thousands of classes? How can you say to use a Java package instead of Java modules? Of course, you shouldn't overuse Java modules. but they are not comparable.