How to Structure Modern Enterprise Java Projects
HTML-код
- Опубликовано: 26 сен 2024
- 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.
For more information see: blog.sebastian...
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.
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.
Hi Higor, ok fair enough :) From my experience in projects, it's usually the architects who didn't touch code for a while who come up with more "abstract"/dogmatic and less pragmatic requests (and also who argue the hardest when I come to question the reasoning behind overly complex structures), but you're absolutely right, there are tons of reasonable, great architects out there (and many over-engineering developers), so no, I don't want to demonize a particular role :)
Modules make sense to use. Cache optimization, code reusability, encapsulation, etc...
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"?
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
Good point, but from my experience it's not worth the extra effort. Compilation in Java takes a very short time and was not an time issue a single time for me in all these years, but rather the overall build time with executing tests, resolving modules, etc. I can mostly speak for Maven, but the time for just compiling all sources rarely exceeds 2-3 seconds, even for large (enterprise project) codebases... With tests, of course, that's a different issue, but then I'd rather split different into test suites or projects.
Great video !!!
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.
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.
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?
Yes, I'd just import the classes
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.
Thank you :)
- Yes, for these functionalities, it makes a lot of sense to create library projects that are then used as dependency.
- Yes, I also prefer having them in the same project, if possible. This only changes when different teams (frontend / backend) have totally separate tools or life cycles.
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 |
?
Well, if you think geometrically (or in shape of a cake: layers vs. slices) then yes, but in my command line a list of directories is always displayed vertically :) But point taken :)
Hello.
What should I do if I need common interfaces/abstract parent classes for some packages?
If it's not too many I usually keep them in the app root package, or have a dedicated one (such as the name of a common entity, etc.) where they are placed
Thank you
Great stuff! If I have to create one or two reusable class, should I left them in the same packages level?
If it's only used in that package level, I'd say yes -- you could then also lower the visibility, e.g. package-private.
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.