Smeagol comprises of Bounded Contexts (BC) in terms of Domain-Driven Design (DDD) that ideally would share nothing. This promises to separate domain from technical concerns. It divides complexity into different Bounded Contexts.
As the account must be read from the session in all BCs, we avoid duplication by using a Shared Kernel.
The shared kernel hosts classes, which are required by each BC.
This BC is responsible for the whole process of authentication.
The Repository BC is responsible for the listing of available repositories and their branches.
The Wiki BC is the heart of Smeagol and is responsible for the wiki itself. This part was previously realized with Gollum.
Within each Bounded Context we use our interpretation of a hexagonal architecture (aka Clean Architecutre, Onion Architecture, etc.) with the following layers:
- Domain: Contains Domain logic only (no technical stuff). Defines value objects, entities, repository interfaces and services.
- Use cases: Exposes actions (write operations) that are possible on the domain. We use the Command Bus pattern here. Advantage: Commands provide an overview of domain operations allowed by the system. They are implemented using a concrete pattern and are not just another thing called "service".
- Infrastructure: Contains all the technical stuff: REST controllers, repository implementations and all the glue.
Access is only allowed in the following direction: Infrastructure -> Use cases -> Domain
The UI uses a Flux based architecture, which is build with Redux. The code is separated in a shared kernel and the BC's analog to the REST API. The shared kernel consists only of components which are required in each BC, some infrastructure and bootstrap logic. Each BC is divided into components, containers and modules.
- Components should be stateless (or should only have a local state). This means each required property must hand over by a higher ordered intelligent component.
- Containers are higher ordered components and this are the components which are connected to the store.
- Modules are the last part of the puzzle. Modules are responsible for the state of the application. They manage the actions and reducers which are required to modify the state.
Access is only allowed in the following direction: Containers -> Components -> Modules
TODO: modules is to general, perhaps store?
Mapping to Code
- Shared Kernel: Base Package
com.cloudogu.smeagolThe base package also contains the entry point of our application.
Bounded Contexts map to subpackages of the base package, e.g.
The hexagonal layers map to subpackages of the individual Bounded Context packages, e.g.
- Shared Kernel: The .js files directly under js
Bounded Contexts map to folders, e.g.:
- Containers, components and modules are mapped to sub folders of each Bounded Context.
- Repository: repository in terms of DDD for accessing -> Note: We also have a domain object called repository referring to a Git or SCM-Manager repository
- Controller: REST Controller, i.e. endpoint (returns resources).
- Resource: DTO that maps entity to the REST interface (returned by a Controller)