ADR: DDD for Federation

Status

WIP

With federation we introduced a topic independent to existing gitea. This will give us the chance to choose other architecture principles.

tbd

Let’s do federation related stuff following DDD as whole. But let’s keep the existing codebase as is.

Reason for this proposal are:

Federation is new, so it might be possible to adjust the architecture for the new code. For existing (f3 code) we might find a way of migration and I offer help :-)
Keep the existing functionality in existing layout will keep compatibility for gitea contributions - as long as we can use them.

Entities and value structs: they contain as much domain logic as possible.
Aggregates: they are atomary units in terms of persistence. This, however, has still some room for improvement :)
Interfaces for infrastructure: infrastructure is encapsulated from domain logic by interfaces. This allows unit testing in combination with mocks.
Service: services provide logic that does not belong to a single aggregate or entity, or is using infrastructure.
Poor man’s dependency injection: services contain infrastructure implementations. This allows to differentiate composition of used infrastructure between production or test usage. This also has room for improvement, because we do not have an application context singleton (as in Spring Boot).

We can unittest all paths in service. Integration test has only to cover the most important paths like “Happy Path” or “Failure Path”.
We can decide to separate domain from domain_test
We can split up the (in future probable) huge federation service along the domain aggregates FederationHost, User. This will lead to packages domain/FederationHost having a FederationService or domain/User having a UserService. This will help to keep the services focussed around one domain.
Refactorings of domain stays simple, as we have all paths under unit tests.
Aggregates are way to model out meaningful submodules in terms of domain. We can improve & sharpen this model in a iterative way. Therefor are Aggregates also the point defining the shape of used repositories and apis.
Aggregates bring the chance of performance improvements: If accessing db multiple times for one use case in my experience often leads to bad performance compared to “load all on start & save all at the end”. But minimizing the times of accessing db stands against amount of data being loaded every time. A good & sharp modelled aggregate might reflect the sweet spot between both bad performing borders.