The application is a Spring based application, of course it is deeply tied to Spring :). JpaRepository comes from Spring Data which is an important dependency of the application.

- Some domain values use plain types instead of value objects. For example, barcode.

The barcode is defined as a Java Record which makes it a value object. What would be a value object to you?

- Business errors are modelled used exceptions.

Agreed, but this example is not intended to highlight best practices around exception handling.

- Loading the current date directly in the constructor is a bad practice, it severely complicates testing

Good point!

- Enum values could (and should) be compared by equal operator, rather than equals().

Thanks, will update this!

- Discussion of the coupling in the context of the availability has no sense, not just because it's a monolith. Separation of the subdomains into the separate microservices is an antipattern and directly contradicts microservices definition.

As per which microservices definition? You seem to be confusing between domain and subdomain. Domain is the business itself while subdomains are fine-grained areas of business activity.

From the book "Learning Domain-Driven Design" by Vlad Khononov,

"Aligning microservices with subdomains is a safe heuristic that produces optimal solutions for the majority of microservices. That said, there will be cases where other boundaries will be more efficient; for example, staying in the wider boundaries of the bounded context or, due to nonfunctional requirements, resorting to an aggregate as a microservice. The solution depends not only on the business domain but also on the organization’s structure, business strategy, and nonfunctional requirements."