Spring Boot Code Structure: Package by Layer vs Package by Feature
Vložit
- čas přidán 7. 09. 2024
- In this tutorial we will take a look at how to structure your code in your Spring Boot applications. First we will cover some best practices or things you should avoid. After that we will cover 2 ways to structure you code and what the pros and cons of each approach might be.
🔗Resources & Links mentioned in this video:
Components vs Beans: • Spring Beans Showdown:...
GitHub Repository: github.com/dan...
👋🏻Connect with me:
Website: www.danvega.dev
Twitter: / therealdanvega
Github: github.com/dan...
LinkedIn: / danvega
Newsletter: www.danvega.de...
SUBSCRIBE TO MY CHANNEL: bit.ly/2re4GH0 ❤️ - Věda a technologie
Dan, it would be great a demo with a comparison of Hexagonal architecture ,Layer, Package
We are working towards that...one step at a time.
Hexagonal architecture just makes unnecessary complexity to your project.
In my latest Spring Boot 3 tutorial, I adopted the "Package by Feature" approach. In my old Spring Boot 2 tutorial, for the same running example, I used the "Package by Layer" approach.
If you are interested, please take a look. Feel free to provide any feedback.
@DanVega waiting on the above request. Just a reminder. That will be really helpful for community as there is so much of confusion around this concepts which and how to use.
For a total beginner this video is packed with useful information. Thanks for explaining it in Layman's terms.
So glad that you found this useful, thank you!
I packaged by layer for years. Until I saw some people packaging by feature and I thought that was a crazy idea. Until I tried it myself. I found package by feature is very nice for large projects. No going back for me.
Thanks for sharing!
I do package by feature 100% of the time.
Love it! I was iffy about posing this question in office hours a few months back, but after seeing how much engagement there is on this video I'm so glad I did and am not the only one that was interested!
Hi Dan. Thank you for another great video.
I clearly see the benefits of the package by feature approach. However, I am wondering what your opinion is on implementing relationships between the entities. For low coupling I imagine that every package would only have one single point of entry for other packages (e.g. a service or interface exposed to be used by other features). In which case how would you go about designing the relationships between the entities? You ofc won't be able to leverage the Spring Data JPA annotations so I guess you would create DTOs between the features (which, in my opinion, may introduce unnecessary complexity depending on the size of the project). And maybe just storing the id of the referenced entity? Is some leakage acceptable?
Let me hear your opinion, thank you! :)
Short video but proving the good overview. Thanks for that.
Glad it helped
Killing it... always love to watch your videos 😉
Thanks, Dan - this is very insightful as always!
Aside from just sounding right, generally speaking, the biggest upside for me is the ease with which you can fork out a microservice when packaging by feature (and maybe modularity to a certain extent). That is a good litmus test on how cohesive and less coupled your code is.
But then, you don’t create new projects every day, so you’re basically stuck with whatever the original authors intended, and that’s usually packaging by layer.
Great article/video! Thank you!
Thank you!
This was very useful. You've just gained a new subscriber in me!
I generally work by packaging by feature and then layers within as you mentioned at the end. In my code each feature module stays quite compact but the additional layer packages give me a bit of structure and make it easier to navigate the code. Its usually up to 20 files per feature, 2-3 services, 7-10 use case interfaces, entities, DTO-s for Inputs and outputs, filtering etc.. I think the boundaries between features are clear and not an issue at all even though i lose the package visibility benefit of packaging by feature in a flat package.
What i really struggle with is having Data JPA relationships having references to other feature entities. I feel like Data JPA is not well suited for this way of structuring code, or I am not using it correctly.
So as an example in sports, having a "Matches" Feature, and a "Teams" feature, where a match references a team, but a team is also standalone. So if i just use teamId in match its really hard to query (lets say i want to get a list of matches filtered by a specific team), so i have a JPA OnetoMany relationship there.
Really great explaination!
Good video. Thanks for making such useful videos
Thank you for watching them David!
This all makes sense until we begin doing something more complicated. Let's say we have Authors, who write the posts. Naturally we want our entites to have relations. This way we no longer can make entity classes package-private. We also create coupling. In the end, the whole idea of package by feature becomes not viable. At least not in the way presented in the video. In my experience module will always contain all the stuff, which is related to each other in some way. An we come back again to package by layer. True modularity is possible only on not related stuff. e.g. i18n module for our FE.
What do you think about that?
I think your article lacks the "comment" implementation to make clear the boundaries of layer vs feature, to show us how comment and post will relate to each other.
Agree that can also be a discussion on DDD
Thanks Dan
In package by feature, would you put a security config into a config package, or a security package? What about a controller advice?
I put them of a package called shared/configs/SecurityConfig
What should be done when a model in a feature package has a relation with other models outside of the feature package, such as when a Post model has a relation with a Comment model? Is there any way to handle that?
Just the GOAT
You just mae my day!
Great video
If you doing monolithic apps package feature is more maintainable for microservices package by layer.
what about a package strucuture with 4 main packages: api (containing other packages such as controller, mappers/assemblers, listeners), domain, core, infrastructure? Then the tradicional layer package within domain, core and infra?
I also like this approach the best but I have a question. When I access from a service in one package to another service or a repository etc. in a different package, is that OK?
My second question is is there a resource like a book or video series or something similar to learn more about this approach in more details?
Very interesting discussion indeed. If a service A need a service B datas to build a response, how you handle this in feature design. You need to keep public accessor, is n it ?
I generally prefer package-by-feature. But: I also like API-first development (generating controller interfaces using OpenAPI Generator for example) and I feel it clashes a little with the package-by-feature approach, because you generate an entire "layer" (the controllers) in one go, and all the results tend to be put in the same package. Is there a solution to this apparent tension?
X2
i have to try package by feature one day. But i wonder what happens when i have 50 domain objects for different services
Hi Dan,
In a scenario where the API-First methodology is employed, and we have an openapi.yml file representing all the operations of our API (in this case, the blog API), I understand that in the case of a layered architecture, we would typically have a BlogController where we implement all our methods. However, in the case of adopting a feature-based architecture, would we create a separate openapi file for each feature, where the specific functionality is implemented? Or would we follow a similar approach as in the layered architecture by sharing this interface among all the features in some way?
I am mixing both types. I found that keeping packages such as: configuration, entities, controller, dtos, and mappers as "Package by Layer" works well, but I organize all services in the following manner:
services
---- product
-------- business
In this package, you can find our main code. Everything we have to write manually, come up with, etc., is because it's business-related. This package should also be tested 100% by unit tests.
-------- data
Here we have a package where we can find all the classes from which we obtain data for a product. We can source this data from databases, external services, etc. There is no logic; the primary responsibility is simply to retrieve raw data from external sources.
I find this structure the most readable. I disliked searching for controllers or entities using "Package by Feature". On the other hand, writing clean code with tons of business classes in "Package by Layer" is not possible, or at least I've never seen it done.
Shouldn't we call packages plural like controllers, models?
Or that's just up to us to call model or models?
is it possible to do a packaging by layer inside the features , in my case i have a lot of DTOs and and sevral repositories since the feature containe many entities , and i want to know is it correct to split them by layers inside the feature package ?
Thanks for doing this
@DanVega Could you also make a video comparing java packages vs maven modules when structuring your application
the only advantages of having maven modules are if you have different teams taking care of the same software. Usually a maven module project is bundled to only one jar or war.
thankyou sir of such contents
Great Explanation!!
What about Global Exception Handler and Security configurations in package like feature structure?
I'd usually store them by according to their scope. For example, I keep Global Exception Handler under web package as it's about translating Exceptions to HTTP status.
What do you think about multi-module approach?
Coupling between layers can be mitigated by interfaces, no?
How will test be written if the classes are not public in the package by feature version?
Thanks for video but too much time spent on explaining package scanning.
I have been worked on different projects and can say that if there is a shortcut, good lazy developer will take it.
Using any of mentioned approaches without discipline will sooner or later lead to spaghetti code and dependency mix.
Personally, hexagonal architecture seems like overhead at the beginning but it puts constraints and at the end there is benefit from it.
All the best!
Code explosion. All classes except for the Service differ(almost) only in name. Should they even exist?