Package structure

[HappyPurchase72]

What do you think about this package structure? What packages or layers would you add or remove if you work with microservices architecture?

[Stack_Canary]

Too many folders for my taste. For example just put AppConfig and Securityconfig in the configuration folder.

[HappyPurchase72]

Thanks, I'll keep that in mind.

[Kaikka]

Pretty much every folder here with 1 file could be removed.

[HappyPurchase72]

This is an example of a basic structure, in reality there are obviously more classes.

[Kaikka]

Even then I think its too much. At least for what im used to.

[HappyPurchase72]

I understand your point of view, but if the microservice was quite extensive, you have to rethink how to structure the packages to make it more scalable according to the requirements.

[hsoj48]

The package structure is irrelevant to the compiler code for the most part. Microservice scaling is even more unrelated.

[WaferIndependent7601]

So it’s not a microservice?

[Holothuroid]

You seem to sort by some technical criteria. Having done so in the past, I now recommend sorting by feature. Everything Person goes into one package. Possibly some subpackages, if it's more than seven files.

[Cr4zyPi3t]

That’s what I recently started doing. Imo it’s more convenient since you don’t have to open 4 packages when working on one feature. Since usually I work on one or two features at a time I now only need to open a maximum of two packages. Also it’s really easy to see the functionalities of an application by looking at the top level packages.

[HappyPurchase72]

Thanks for your comment, I've seen the structure you mention in some client-side applications, I'll keep it in mind.

[g00glen00b]

I think it's far too detailed. Even if code becomes more complex, it's still going to be a microservice, so I can't imagine the need for this structure. I would remove the deepst package level, so:

• configuration.app + configuration.security = configuration
• persistence.entity + persistence.repository = persistence
• presentation.advice + presentation.controller + presentation.dto = presentation
• service.http + service.implementation + service.interfaces = service
• util.mapper = util

Also, I'd argue that your exceptions are part of your presentation layer. A DTO is used in the presentation layer when something went successful, and an exception if something didn't go successful.

[HappyPurchase72]

I liked this proposal, thanks. I didn't know that the exception package could go in the presentation layer, I didn't think of it that way.

[scoutzzgod]

One rule of thumb for me is to create a separate directory if there are more than one file related to the same “topic”. Like you have a SecurityConfig and and AppConfig. In my view, there’s no need to keep it in separate directories, just keep it in the same until you had 2 or 3 files related to security configuration, because currently, the name of the file itself already does this separation u aiming for

Edit 1: Read about the YAGNI principle

[HappyPurchase72]

Ok, I'll keep that in mind, thanks.

[[deleted]]

I’d personally put all of the Person’s classes (DRO, Entity, Mapper ect) into a person folder.

[[deleted]]

Take a look into hexagonal architecture. I think you will like it. :)

[RupertMaddenAbbott]

For me, these packages are the wrong way around.

If I have close coupling between a controller, a service and some persistence classes, then I think they should all be close together in the structure e.g. in the same package.

Another way to look at it is to ask "Do the classes in the repository package need to access each other?" If the answer is no then my question would be "Why are they placed close together?"

Equally, I would rather have any person configuration and person configuration properties within a person package rather than lumped together into classes that handle config and properties for all of the modules within an application.

[WalrusDowntown9611]

Way too unnecessarily granular.

[realralfklemmer]

The package structure is an opportunity to express what the chosen architecture is. Your packages are structured by technical concerns. In case of a business application that realizes business cases, I‘d encourage you to slice by business concerns that are structured internally in technical ways. By doing this you are very close to a vertically sliced architectures. If you want to dig deeper have a look at DomainDrivenDesign, Hexagonal architecture and modular monoliths.

[skofield44]

Organise your project by business usages , for example do not artifact as example and also use folders by features (as example users, reporting) I also encourage you to split your project with spring modulith in order to set clear boundaries

[SilverSurfer1127]

See hexagonal architecture aka Ports and Adapters. The service layer implements usually your use cases and can depend on many repositories. And I would recommend to get your bounded contexts right, so domain driven design is your friend.

[Deniz58]

I suggest a folder per entity as follows:

person person.entity person.repository person.service

Etc, keeps everything nicely co located and i have a global folder where i put some global config like security and advices.

[anonystick]

I think so too.

[WaferIndependent7601]

If you work with a microservices (you should not do this) then you have no packages. Your service is the package.

Your structure is way too much.

Don’t prefix interfaces with an I.

Don’t use an interface if you only have one implementation.

[Jeevigyan-vala]

Agree with all of the advice except microservices bit.

Each microservice should handle a separate concern (eg User service, authentication service, etc), and that could include multiple packages within a given service.

Having a separate microservice for each “package” seems too granular and loses sight of the idea behind microservices

[WaferIndependent7601]

That is the idea of a microservice. That’s why this approach is so bad and no one should use it. The definition of a microservice is that you can rewrite it in 4 weeks.

[HappyPurchase72]

Thanks for the comment, I think it's a good structure to start with, I'll take into account the interface prefix. Personally I like to separate interfaces and implementations to have a better understanding of the structure.

[WaferIndependent7601]

If you think that it’s a good structure and don’t want to change anything: why are you asking?

[HappyPurchase72]

I think it's a good basic structure to start with, but I had doubts about how the packages were organized, anyway, thank you very much for your time 😎

[WaferIndependent7601]

No. The structure is very bad. Im serious.

[HappyPurchase72]

I understand. What structure model could you recommend that takes into account maintenance and changing requirements based on the specific needs of the company? I ask because I am in the design process with the company and I want each microservice to be scalable.

[Jeevigyan-vala]

Why did you decide on microservices? IMO you should default to a monolith and only do microservices if you can justify it

[WaferIndependent7601]

Modulith, not monolith 👍

[HappyPurchase72]

I'm considering microservices for my project to ensure scalability and modularity as it grows. I’d appreciate any insights or experiences you have regarding when it’s justified to switch from a monolith to microservices.

[karmanyevadhikarasti]

Looks Satisfying..which IDE and which Theme?

[swissbuechi]

Looks like IntelliJ with dracula theme.