mirror of
https://codeberg.org/forgejo/docs.git
synced 2024-11-24 18:09:26 -05:00
64fe34712f
Rename Developer to Contributor guide - I believe this sounds more inclusive and likely improves the diversity of contributors. Separate translation section clarify external resources Add links to UI/UX and user research repos Separate issue tracker and discussions - I imagine this is part of the confusion for people who report bugs to the discussion tracker. Add welcome section Reviewed-on: https://codeberg.org/forgejo/docs/pulls/821 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Otto Richter <git@otto.splvs.net> Co-committed-by: Otto Richter <git@otto.splvs.net>
3.2 KiB
3.2 KiB
| title | license |
|---|---|
| ADR: DDD for Federation | CC-BY-SA-4.0 |
Status
WIP
Context
With federation we introduced a topic independent to existing gitea. This will give us the chance to choose other architecture principles.
Discussion see: https://codeberg.org/forgejo/discussions/issues/179
Decision
tbd
Choices
1. Do federation stuff following Domain Driven Design in combination with Dependency Injection
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.
Code-Example can be found here: https://codeberg.org/forgejo/forgejo/pulls/4193
1.1 Aspects and Properties
- 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).
1.2 Expected Benefit
- 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
domainfromdomain_test - We can split up the (in future probable) huge federation service along the domain aggregates
FederationHost,User. This will lead to packagesdomain/FederationHosthaving aFederationServiceordomain/Userhaving aUserService. 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.