some changes

AEP/aep-0000x.md

@@ -17,30 +17,30 @@ This AEP proposes a new architecture for ArmoniK's extension, aiming to create a
 
 This AEP aims to create a standard architecture for ArmoniK's extension development. It proposes services decoupling, segregating interfaces to related domains, and enriching domains.
 
-# Proposed Solution
-
 The proposed architecture will:
 - Define a clear architecture for development.
 - Introduce a modular design to ensure extensions can be developed and tested.
 - Enhance the user interface to make the integration process more intuitive.
 
-## Specification
+# Specification
 
-### Domain Segregation
+## Domain Segregation
 
 To improve clarity and structure, the ArmoniK SDK will keep domain segregation to ensure modularity and ease of use. These domains will encapsulate related services and functionalities, promoting a separation of concerns and enhancing maintainability and scalability:
 
-- **Session Domain**: Responsible for managing sessions and their related operations.
-
-- **Data Management Domain**: Manages data entities within ArmoniK, including results and its metadata. This domain provides services for creating, uploading, and downloading data results.
+- **Task Domain**: Manages tasks, offering functionalities for task submission and monitoring. A task is an atomic computation taking one or several input data and producing one or several outputs. Tasks are process that execute on 
+
+- **Data Domain**: Manages data entities, inputs and outputs of a Task execution. This domain provides services for creating, uploading, and downloading data results.
+
+- **Session Domain**: A session is a logical container for tasks and associated data (task statut, results, errors, etc). Responsible for managing sessions and their related operations.  
 
-- **Task Management Domain**: Manages tasks, offering functionalities for task submission and monitoring. It ensures tasks are managed efficiently and effectively.
+- **Observer Domain**: 
 
-### Handlers
+## Handlers
 
 To enrich the behavior within each domain, we introduce the concept of handlers. Handlers enable domains to contain their own specialized behaviors and functionalities. For instance, a `TaskHandler` might offer a extension method to get detailed state information of the task.
 
-### Services
+## Services
 
 Each domain will contain specific services to encapsulate its functionalities:
 
@@ -53,7 +53,7 @@ Each domain will contain specific services to encapsulate its functionalities:
 - **Task Management Domain**:
   - **TasksService (`ITasksService`)**: Manages tasks, offering functionalities for submitting and monitoring tasks.
 
-### ArmoniKClient
+## ArmoniKClient
 
 Interaction with ArmoniK will be managed through the `ArmoniKClient`, which oversees all services and channel pools. `ArmoniKClient` exposes functions that allow users to access these services, promoting a cohesive and intuitive user experience: