Note: this is work in progress, it will be presented for Tech Committee
...
- AuthenticationHelper goes to Application layer since only this layer should be responsible for security handling,
- MoneySerializer/MoneyDeserializer goes to Web layer as this layer is responsible for user interface, so for de/serialization from/to JSON)
- RequisitionHelper code should be refactored and find its place in DDD building blocks in Domain layer (some code goes to Entity, some to ValueObjects)
Exception package
This pakage should be removed. We should follow our style guide: Exception classes should go with the classes that throw the exception. If more than one layer use Exception it should be placed with given order: 1. domain; 2: service; 3: web
Validate package
Eventually, we want to get rid of this package. Business logic validations should find place in domain layer, constraint validations should be at database level, all others in application layer.
Open questions:
- Overall: makes sense to align around a typical 3 layer arch: presentation, domain, repository: https://martinfowler.com/bliki/PresentationDomainDataLayering.html
- In infrastructure layer, it really just looks like a repository layer.
- A seperation of "web" and application service makes sense to me
I modified structure aboce
- Use of package private scope of Java - we could use a more concrete plan to see if we're taking advantage of this
I created simple UML to show how it will look
| View file | ||||
|---|---|---|---|---|
|
- Should database repositories and repositories that are backed by a different service use the same interface? Consider potential differences in error handling.
No, different interface for database repositories and repositories that are backed by a different service
- Is the repository name overused when used for both database backed and service backed?
I don't think so. Domain layer shouldn't really care if some data come from database or other service. Domain layer should be free from technical complexity. I would even say that currently 'service' name is overused currently, in DDD repository has simple definition: retrieve and persist domain objects from bounded contexts. On the other hand, in Repository layer-package we will easily distinguish type of repository by prefixes like: Jpa*, Rest*, e.g. JpaRequisitionRepository
...