fix: Propose anemic domain models

The reason for the anemic domain models lies in two things.
First of all are the domain models returned to the adapter.
But business logic should not be moved outside.
An additional mapping should be avoided.
Furthermore in large scaled applications anemic domain models are much
easier to handle, because the business logic is not spread across use
cases, domain models and services.
Making the applicaiton easier to understand

Author: Fabian Baumeister

modules/ROOT/nav.adoc

@@ -2,6 +2,7 @@
 ** xref:getting_started/create_rest_service.adoc[]
 * Architecture
 ** xref:architecture/layered_architecture.adoc[]
+** xref:architecture/hexagonale_architecture.adoc[]
 
 * Integration
 ** xref:integration/rest_service.adoc[]

modules/ROOT/pages/architecture/hexagonale_architecture.adoc

@@ -115,8 +115,7 @@ image::hexagonal_component_architecture_overview.drawio.svg["devonfw hexagonal a
                     ├── ReservationJpaMapper.java
                     └── TableJpaMapper.java
 ----
-
-[cols="1,1", options="header"]
+[cols="20,~", options="header"]
 |===
 | Package | Description
 
@@ -126,7 +125,7 @@ image::hexagonal_component_architecture_overview.drawio.svg["devonfw hexagonal a
 | core.domain
 | The domain circle contains the entities and value objects of the business domain of the application. 
 Related Factories or Builders are located here as well. 
-The entities in our domain are usually rich. 
+It's proposed to make entities anemic. See <<_anemic_vs_rich_domain_models>>
 
 | core.usecase
 | Use Cases are the main entrypoint of the applications core. 
@@ -191,3 +190,29 @@ Inside the adapters further packages are differentiating the protocols that is u
 That can be database connections, file operations, API calls, message producing and many more.
 Inside the adapters further packages are differentiating the protocols that is used (e.g. `.jpa`).
 |===
+
+
+== Anemic vs Rich domain models
+====
+"In a rich domain model, as much of the domain logic as possible is implemented within the entities at the core of the application.
+The entities provide methods to change state and only allow changes that are valid according to the business rules. [...]
+In an “anemic” domain model, the entities themselves are very thin.
+They usually only provide fields to hold." <<Hombergs21>>
+====
+
+Considering java as an object oriented language it feels natural to implement business logic inside the entities themselves. 
+In large scale application with mixed skilled people it's proposed to not use rich domain models.
+There are two reasons for this.
+First of all, the domain objects are returned to the adapters. 
+If they include business logic this is revealed and available outside of the core, which should not be the case.
+The answer to this problem could be an additional mapping, but this leads to a lot of unpractical mappings.
+Furthermore, adding the business logic to the domain entities spreads it across use cases, entities and services. 
+This makes the application more difficult to understand and harder to locate the place for new features or changes.
+
+It's proposed to implement the domain model as anemic entities using Java records.
+Use use cases and services to implement the business logic and interact with the domain models.
+
+
+[bibliography]
+== Bibliography
+* [[[Hombergs21]]] Tom Hombergs. _Get Your Hands Dirty on Clean Architecture._ 2021.