Is it normal to put domain logic inside setter methods in an Entity class? Or a bad idea?

For eg, I have a Domain Service that contains business validations and other domain logic. I also have Application Services that handle different use-case scenarios. Right now, my Entity has a public setStatus() method, which means anyone can call it and bypass the validations in the Domain Service. I cannot make setStatus() protected because the Entity and the Service are in different packages.

What’s the standard approach Spring developers usually follow here?
Do people typically move the logic into the setter/entity method instead of the Domain Service?

What if the logic really belongs in the Domain Service because it depends on external dependencies or other services?

I'm trying to understand how Hibernate behaves in different situations. Does anyone know of any good resources or quick tests I can run to better understand how it works?

Right now Im specifically trying to understand lazy loading behavior.

Suppose we have 3 entities: organization -> department -> employee

• A Department has a ManyToOne relationship with Organization.
• An Employee has a ManyToOne relationship with Department.

Case 1: Load departments first, then employees.

In this case, I'm able to navigate from Employee -> Department (e.getDepartment().getId()) without triggering additional queries.

List<Department> departments =
    departmentRepository.findAllByOrganizationId(organizationId);

List<Long> deptIds = departments.stream()
    .map(Department::getId)
    .toList();

List<Employee> employees =
    employeeRepository.findAllByDepartmentIdIn(deptIds);

// No additional queries triggered
Map<Long, List<Employee>> groupedById =
    employees.stream()
        .collect(Collectors.groupingBy(e -> e.getDepartment().getId()));

// No additional queries triggered
Map<String, List<Employee>> groupedByName =
    employees.stream()
        .collect(Collectors.groupingBy(e -> e.getDepartment().getName()));

Case 2: Load only employees.

Now, accessing e.getDepartment().getId() does not trigger queries, but accessing e.getDepartment().getName() does.

List<Long> deptIds = List.of(1L, 2L, 3L);

List<Employee> employees =
    employeeRepository.findAllByDepartmentIdIn(deptIds);

// No additional queries triggered
Map<Long, List<Employee>> groupedById =
    employees.stream()
        .collect(Collectors.groupingBy(e -> e.getDepartment().getId()));

// Triggers N+1 queries
Map<String, List<Employee>> groupedByName =
    employees.stream()
        .collect(Collectors.groupingBy(e -> e.getDepartment().getName()));

Is this behavior consistent and expected in Hibernate?
How should I think about this internally so I can predict and plan for these situations properly?

From a proper architectural point of view, what’s the best way to handle parent/child entity services?

This might sound like a beginner question, but I’m trying to improve my backend design skills and would appreciate guidance from more experienced developers.

Suppose we have 3 entities: organization -> department -> employee

• A Department has a ManyToOne relationship with Organization.
• An Employee has a ManyToOne relationship with Department.

So consider 3 services and repositories, with each service containing its own repository:

• OrganizationService + OrganizationRepository
• DepartmentService + DepartmentRepository
• EmployeeService + EmployeeRepository

Creation flow

1. We can independently create an Organization.
2. A Department can only be created with a valid Organization. In this case, should DepartmentService depend on OrganizationService (to fetch/validate the Organization. Basically DepartmentService contain OrganizationService too)?
3. Similarly, an Employee can only be created with a valid Department. Should EmployeeService depend on DepartmentService?

Is this the standard approach? Or is it better to introduce something like a facade/application layer that orchestrates these operations and passes required entities down to the services?

Deletion flow

1. If we delete an Organization, how should child cleanup typically be handled?

Possible approaches I can think of:

• Approach 1: Parent services directly depend on child services for cascading deletes. Example:
  • OrganizationService -> DepartmentService (Basically OrganizationService contain DepartmentService too)
  • DepartmentService -> EmployeeService
• Approach 2: Use ORM cascade operations (OneToMany + CascadeType.REMOVE / orphan removal) and let Hibernate handle child deletion automatically.

What is generally considered the cleaner architectural approach?

1. Do you usually define OneToMany relationships everywhere they’re needed for synchronized operations (create/update/delete), or only when navigation from parent to child is actually required?

Would appreciate insights on how this is typically handled in real-world backend applications.

I have a 2015 WagonR. Since last year, I have occasionally noticed a petrol smell near the front/bonnet area after driving for around 20-30 minutes. It seems to be more noticeable when the AC is on (not completely sure though).

I also notice a petrol smell inside the cabin. Usually after driving with the AC on for 20-30 minutes, if I step out of the car and then get back in, I can clearly smell petrol inside. While driving, I don’t notice it as much.

When I first noticed this, I asked a local workshop to check it. They told me to bring the car in when the smell was actually present, but the issue disappeared for a few months at that time. Now the smell has come back again and has been happening for a while.

Has anyone faced something similar? What could be causing this?

I’m learning Spring recently, but I often get confused about where to put specific logic / lines of code.

1- To fetch all the addresses of a User, I get the current authenticated username using principal.getName() in the ProfileController and then pass it into the AddressService method getAllByUserUsername(String username) , it then calls findByUserUsername() in AddressRepository and returns the List. Is this the right way ?

.

2- To open selected address's form-edit of a User, I get the current authenticated username using principal.getName() in the ProfileController (same as above). The addressId is obtained from \@RequestParam. The controller then pass both into the AddressService method getByIdAndUserUsername(Long AddressId, String username) , it then calls findByIdAndUserUsername() in AddressRepository and returns the Optional.

The obtained Address is then converted into a AddressProfileForm in the ProfileController (I hope this is the right place.??) and then given to the Model. I believe converting the Address into a DTO (Request/Response/Form object) couples the UI/Form design with the Business logic in Service and feels wrong, right ?

.

3- To submit the above form-edit or a new-form, I get the current authenticated username (same as above). I get the Form using \@TheModelAttribute. The addressId is also available in the AddressProfileForm (if edit). The ProfileController checks for AddressId in the form:-

-> If its null, it calls the addAddressForUsername(String username, AddressProfileForm addressProfileForm) in AddressService. The AddressService then also fetches the User using UserService (Yes, the UserService is also present in the AddressService just for this purpose, is this right ??). It then creates a new Address object and passes to the save method in AddressRepository.

-> Else, it calls the updateAddressForUsername(String username, AddressProfileForm addressProfileForm) in AddressService. The AddressService then fetches the target Address using getByIdAndUserUsername(Long AddressId, String username) , replaces its fields with the new ones in DTO and then save it.

.

My doubt is:
-> using DTOs in service tightly couples it with the UI/API DTOs (Request/Response/Form object) and makes it less reusable. Is that a valid concern?
-> Constructing the Entity Object (Mapping from DTO to Entity) in the controller feels wrong , exposing the internal/business/database datatype.
-> Using UserService in AddressService feels wrong, should I make a ProfileService/ProfileFacade to connect the two or would that just add unnecessary complexity?