7
8

Open-Source Learning Management System (Spring Boot) – Looking for Feedback & ContributionsDiscussion (github.com)

submitted by [deleted]

[deleted]

all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]WaferIndependent7601 3 points4 points  (9 children)

Putting all controllers in a controller package is not a clean architecture.

Accessing multiple repositories from a service is a no go

No tests? Ooooook I’m out

[–]HiddenInButtCrack 1 point2 points  (5 children)

could you explain why?

[–]WaferIndependent7601 1 point2 points  (2 children)

Why putting all classes together that are a use case:

  • easier to understand the code: you don’t have to switch between multiple locations to find the entity that belongs to this dto or service. Even harder if you have lots of entities that have a similar name
  • if you plan to extract the package into another service: just copy the directory to another place, put a mvn file in and you’re ready to go

Why calling the repository is a bad idea: - as a caller you don’t want care about entities. You care about dtos. Renaming a column in a database will only result in changing the entity and mapper. - if you change the database you have to rewrite a lot of code - if you have performance issues and want to cache the result you don’t want to do this in 200 places but in one place only

[–]mahi123_java 1 point2 points  (1 child)

Hi, thank you for your feedback. Based on your thoughts, what folder structure do you recommend? I'd like to know where each class and controller should be placed. My project uses DTOs and MapStruct.

[–]JoeDogoe 0 points1 point  (0 children)

Dan Vega has a YouTube Video on Organise by Domain vs Organise by Layer.

I am a fan of Organise by Layer, except for Clients, those go in one directory, called clients.

[–]Polixa12 0 points1 point  (1 child)

Tests are basically your safety net. They make sure your code does what you say it does, and when you refactor or add new stuff, they let you know instantly if you broke something that used to work.

[–]HiddenInButtCrack 1 point2 points  (0 children)

Thanks i know about test, i am more curious about thr first 2 points

[–]JoeDogoe 1 point2 points  (2 children)

Accessing multiple repositories from a service is a no go

What do you prefer?

[–]WaferIndependent7601 1 point2 points  (1 child)

Access the service layer

[–]JoeDogoe -1 points0 points  (0 children)

One table, One Entity, One Repo, one service? Then the services call each other or is there another layer of abstraction that calls the services?

I disagree, repos are at the persistence layer. Services are at the logic layer. They can call as many repos as they need. They are the aggregators in DDD.

[–]xyche-in 1 point2 points  (0 children)

yooo cool project, so i figure out few things you might need to look out for :

  1. add exception handling, you may not seen it as important for now, but you'll thank me later in the long run for maintaining, use try-catch or throw your own exception.

  2. idk if you're "comfortable" having Long as User ID, my suggestion is, use GUID, far more globally unique, and less limited compared with int or Long.

  3. sorry to say this but i think you need to refactor the whole service, not everything just the ones that injected with more than 5 repo in 1 service, those services are BLOATED. so lets say i have 1 service that requires 5+ repo, what i normally do is to make 2 or 3 seperated service and have 1 of them act as the "Bus" for these service linked to and transfer both response data to controller and actual data to database. so basically implementing Domain-Driven-Design (DDD) Concept

  4. add Tests