fix: Review and align with SEAguide

Added review fixes.
Renamed all outbound to outgoing and all inbound to incoming (according
to SEAguide)

Author: Fabian Baumeister

modules/ROOT/pages/architecture/hexagonale_architecture.adoc

@@ -13,8 +13,6 @@ image::hexagonal_component_architecture_overview.drawio.svg["devonfw hexagonal a
 // As the list is easier to maintain, try to do edits in the list structure, use the tool mentioned above and paste both in here:
 
 // - application
-//   - config
-//       - Configuration.java
 //   - core
 //     - domain
 //       - Customer.java
@@ -59,8 +57,6 @@ image::hexagonal_component_architecture_overview.drawio.svg["devonfw hexagonal a
 ----
 .
 └── application/
-    ├── config/
-    │   └── Configuration.java
     ├── core/
     │   ├── domain/
     │   │   ├── Customer.java
@@ -108,7 +104,7 @@ image::hexagonal_component_architecture_overview.drawio.svg["devonfw hexagonal a
 | The core contains the essential business logic, domain entities, and use cases. It focuses on implementing the main functionalities while remaining technology-agnostic. The core interacts with external components through well-defined interfaces called "ports," ensuring a clear separation of concerns and promoting flexibility, testability, and maintainability.
 
 | core.domain
-| The domain circle contains the entities and value objects of the business domain of the application. 
+| The domain package contains the entities and value objects of the business domain of the application. 
 Related Factories or Builders are located here as well. 
 It's proposed to make entities anemic. See <<_anemic_vs_rich_domain_models>>
 
@@ -122,30 +118,30 @@ Depending of the size and adjacency of the use cases a grouping might make sense
 | Ports are interfaces, that are used by the core and should be implemented by an according adapter. 
 Ports should not be technology specific. 
 One big advantage of the hexagonal architecture is, that the adapters can be changed without changing the core and therefore, without touching the business logic. 
-It needs to be distinguished between inbound ports and outbound ports.
+It needs to be distinguished between incoming ports and outgoing ports.
 
 | core.port.in
-| Inbound ports are the entry of the application. 
-They provide interfaces that are called from inbound adapters and hide the actual implementation. 
-A proposal of structuring inbound ports is naming them like single use cases (e.g. CancelReservationPort). 
+| Incoming ports are the entry of the application. 
+They provide interfaces that are called from incoming adapters and hide the actual implementation. 
+A proposal of structuring incoming ports is naming them like single use cases (e.g. CancelReservationPort). 
 Each port should only provide a single method.
 .Design Decision
 [%collapsible]
 ====
-Inbound Ports are not as relevant for the hexagonal architecture as the outbound ports. 
-Outbound ports are used for the dependency inversion pattern. 
-For inbound ports could also call the use cases directly. 
-Therefore, an pragmatic alternative would be leaving out the inbound ports.
+Incoming Ports are not as relevant for the hexagonal architecture as the outgoing ports. 
+Outgoing ports are used for the dependency inversion pattern. 
+For incoming ports could also call the use cases directly. 
+Therefore, an pragmatic alternative would be leaving out the incoming ports.
 
-It was decided to include the inbound ports nonetheless. They should implement single use cases that are offered. 
+It was decided to include the incoming ports nonetheless. They should implement single use cases that are offered. 
 Each interface should clearly mark the use case that contains only one method.
 Use cases from the interface might be grouped logically in the use case implementation class.
 ====
 
 | core.port.out
-| Outbound ports decouple the interaction with external systems. 
+| Outgoing ports are an abstraction of everything in the surrounding context that is actively triggered by the core or used as data sink.
 This might include other services that are called, files that are written, databases, event streaming and everything the application is actively triggering outside of the core.
-Outbound ports should describe the business need for the communication (e.g. StoreReservationPort). How this is then realized depends on the adapter that implements it. 
+Outgoing ports should describe the business need for the communication (e.g. StoreReservationPort). How this is then realized depends on the adapter that implements it. 
 This way a technology can be easily replaced. 
 For example storing the reservation could be be realized in a first prototype by writing the objects to a file. 
 Later it could be replaced with a database.
@@ -154,7 +150,8 @@ The core logic would be untouched by that.
 | [optional] core.service
 | Services can be considered as business helper classes. 
 They provide a reusable part of the applications business logic that is used by multiple use cases or that helps to structure the application in a logical way.
-Services are optional as they can be used, when there's a real need. Usually a use case should contain the business logic.
+Services are optional as they can be used, when there's a real need. 
+Usually a use case should contain the business logic.
 
 | adapter
 a| Adapters connect the application core to the surrounding context. They have the following tasks:
@@ -166,14 +163,14 @@ a| Adapters connect the application core to the surrounding context. They have t
 * Log the interaction with the surrounding context
 
 | adapter.in
-| Inbound adapters specify connection points for everything that can trigger the business logic. 
+| Incoming adapters specify connection points for everything that can trigger the business logic. 
 That might be interfaces (HTML, RPC, etc), Message Consumers or schedulers for batch processing.
-Inside the adapters further packages are differentiating the protocols that is used (e.g. `.rest`). 
+Inside the adapters further packages are differentiating the category of the adapter (e.g. `.web`). 
 
 | adapter.out
-| Outbound adapters define outgoing connections where the application actively interacts with context outside. 
+| Outgoing adapters define outgoing connections where the application actively interacts with context outside. 
 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`).
+Inside the adapters further packages are differentiating the category of the adapter (e.g. `.repository`).
 |===