Spsh 703 update doku (#506)

* update documentation

docs/architecture.md

@@ -9,6 +9,8 @@ Business logic is mainly handled within an Aggregate. If that is not possible, e
 A new Aggregate is created by a factory.<br>
 To load an Aggregate from the persistence layer a Repository is used.<br>
 A changed Aggregate is persisted via a Repository as well.<br>
+A Repository must not expose any data structures related to the persistence layer i.e. DB-entities or ORM related classes or types.
+A Repository should not provide multi purpose methods. If an Aggregate or controller needs to search with specific parameters we create a method just for these specific parameters.
 
 For cross cutting concerns we use Shared Services. Shared services can be injected into Aggregates.
 
@@ -30,6 +32,16 @@ Decide what services to put in the module's `exports`-array instead of defaultin
 
 ## Authorization
 
-Authorization is done in the Aggregates. If a service triggers operations in multiple Aggregates, each Aggregate will need to perform its own check. A users roles and rights should be cached in the request context to not retrieve them for each check.
+Authorization is done in the Domain Layer, in practice the Aggregates. If a service triggers operations in multiple Aggregates, each Aggregate will need to perform its own check. A users roles and rights should be cached in the request context to not retrieve them for each check.
 
 The services do not check the user rights again to avoid code duplication. Even services that are exported from a module rely on the authorization being checked by the calling use cases.
+We do not rely on authorization checks in the controllers.
+
+## Integrity Checks
+
+We need check conditions for data integrity e.g. an organisation of type form (Klasse) can not be administrated by an organisation of type school sponsor (Schulträger), but only by a school.
+To check these conditions we use the specification pattern for reusability.
+An Aggregate can run its own Specifications. This can be done while creating the Aggregate.
+
+Before persisting an aggregate the Specifications need to be checked. The Repository must trigger the check. We do not rely on the controller to do it reliably.
+

docs/developer-notes.md

@@ -5,6 +5,8 @@
 
 ## Object Mapping
 
+The use of **Automapper** is deprecated, because it seems to be unmaintained at present.
+
 We are using a library called [Automapper](https://automapperts.netlify.app/) with the [classes strategy](https://automapperts.netlify.app/docs/strategies/classes)
 and [camel case naming convention](https://automapperts.netlify.app/docs/mapping-configuration/naming-conventions).
 The mapper works annotation based for each property. Every type besides the primitive types (boolean, number, string)

docs/file-structure.md

@@ -18,21 +18,22 @@ src
 │       ├───api - contains use-cases, controllers and API-dtos of a module
 │       │       [some-request].body.params.spec.ts
 │       │       [some-request].body.params.ts
-│       │       [request-body-to-dto].mapper.profile.spec.ts
-│       │       [request-body-to-dto].mapper.profile.ts
+│       │       ([request-body-to-dto].mapper.profile.spec.ts -> deprecated)
+│       │       ([request-body-to-dto].mapper.profile.ts -> deprecated)
 │       │       [controller-name].controller.spec.ts
 │       │       [controller-name].controller.ts
-│       │       [use-case-name].uc.spec.ts
-│       │       [use-case-name].uc.ts
+│       │       ([use-case-name].uc.spec.ts -> deprecated)
+│       │       ([use-case-name].uc.ts -> deprecated)
 │       │
 │       ├───domain - contains the module's services and domain objects which handle the business logic
-│       │       [domain-object].do.ts
+│       │       ([domain-object].do.ts -> deprecated)
+│       │       ([aggregate].ts -> deprecated)
 │       │       [domain-service].service.spec.ts
 │       │       [domain-service].service.ts
 │       │
 │       └───persistence - contains repositories, db-entities and adapters to other persistence systems
-│               [entity-to-do].mapper.profile.spec.ts
-│               [entity-to-do].mapper.profile.ts
+│                ([entity-to-do].mapper.profile.spec.ts  -> deprecated)
+│                ([entity-to-do].mapper.profile.ts  -> deprecated)
 │               [entity-name].entity.ts
 │               [entity-name].repo.integration-spec.ts
 │               [entity-name].repo.ts