[skip ci] update docs
This commit is contained in:
parent
3e54b0a63a
commit
0f7e3790ca
5 changed files with 2 additions and 44 deletions
|
@ -29,6 +29,6 @@ The success or failure is computed automatically in the following way:
|
||||||
|
|
||||||
## Call hierarchy
|
## Call hierarchy
|
||||||
|
|
||||||
Find below an example of a sequence diagram when provisioning a desktop workplace:
|
In the following link you can find an example of a sequence diagram when provisioning a desktop:
|
||||||
|
|
||||||
![img.png](resources/provision-workplace-sequence.diagram.png)
|
[ProvisionDesktopSequence.md](ProvisionDesktopSequence.md)
|
||||||
|
|
|
@ -28,45 +28,3 @@ In the following document we describe how we implement idempotence:
|
||||||
|
|
||||||
https://gitlab.com/domaindrivenarchitecture/overview/-/blob/master/adr-provs/quasi-idempotence.md
|
https://gitlab.com/domaindrivenarchitecture/overview/-/blob/master/adr-provs/quasi-idempotence.md
|
||||||
|
|
||||||
|
|
||||||
## Architecture
|
|
||||||
|
|
||||||
Multiple architectural layers provide different levels of functionality:
|
|
||||||
|
|
||||||
![provs layers](resources/provs-architecture-7.png "Provs architecture")
|
|
||||||
|
|
||||||
|
|
||||||
## Module structure
|
|
||||||
|
|
||||||
For the modules we use domain-drive design according to:
|
|
||||||
|
|
||||||
https://gitlab.com/domaindrivenarchitecture/overview/-/blob/master/adr-provs/ddd-structure.md
|
|
||||||
|
|
||||||
## Module dependencies
|
|
||||||
|
|
||||||
![resources/prov-module-dependencies-5b.png](resources/prov-module-dependencies-5b.png)
|
|
||||||
|
|
||||||
__Explanation__:
|
|
||||||
|
|
||||||
Modules:
|
|
||||||
|
|
||||||
<ol type="A">
|
|
||||||
<li>Common module: has both a domain layer and an infrastructure layer</li>
|
|
||||||
<li>Module with only domain layer: e.g. for very simple logic where no infrastructure layer is needed</li>
|
|
||||||
<li>Module with only infrastructure layer: these are often _utility modules_, which provide a collection of utility functions</li>
|
|
||||||
</ol>
|
|
||||||
|
|
||||||
Dependencies:
|
|
||||||
|
|
||||||
1. Domain layer calls (a function in) the infrastructure layer of the same module
|
|
||||||
* _Common practice of dependencies within a module_
|
|
||||||
1. Domain layer calls (a function in) the domain layer another module
|
|
||||||
* _Common practice of dependencies between modules_
|
|
||||||
1. Base layer calls domain layer
|
|
||||||
* _Usually not recommended!_
|
|
||||||
4. Domain layer calls infrastructure layer in another module
|
|
||||||
* _This sometimes can make sense, e.g. if module B just needs some low-level function of module D instead of full provisioning.
|
|
||||||
However, in most cases it is recommended to call the domain layer of module D whenever possible_
|
|
||||||
5. Domain layer calls infrastructure layer in another module, which only has infrastructure layer
|
|
||||||
* _Common practice for calling utility modules, which don't have a domain layer._
|
|
||||||
|
|
||||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
Before Width: | Height: | Size: 51 KiB |
Binary file not shown.
Before Width: | Height: | Size: 100 KiB |
Loading…
Reference in a new issue