# RECQ Components Design Now that you have defined all the Messages you need to identify the components handling those messages. We need to choose between: * Aggregate * Projector * Projection * Invoker * Service * Saga * Observer ## [Aggregate](/recq-patterns/recq-component-pattern/aggregate.md) Let's start from the Domain logic handling aspects of the application, we have previously individuated the TodoList domain composed of the TodoList, Todo and User entities. The component and also the pattern used to manage Domain Change Request is Aggregate which collect a group of entities in a Tree Relational Structure with a root representing the Consistency Constraint Boundaries and branches or leaves representing functional depending entities. A **TodoListAggregate** is needed to handle TodoListCreateCommands, TodoListDeleteCommand, TodoListAddTodoCommand, TodoListRemoveTodoCommand, TodoListCheckTodoCommand and produce the related events to communicate to the entire system that the state is changed.

## [Projector](/recq-patterns/recq-component-pattern/projector.md) Data changes must be materialized in some way, to create a database representing a practical and queryable system state we need to use a projector that handles Domain Events and writes changes inside a Repository. A **TodoListProjector** is needed to handle TodoListCreatedEvents, TodoListDeleteEvents, TodoListTodoAddedEvent, TodoListTosoRemovedEvent, TodoListTodoCheckedEvent and materialize the changes.

TodoList Projector Handlers (igonre the ErpUserActivityRegisteredEvent will be added in the next tutorial)

## [Projection](/recq-patterns/recq-component-pattern/projection.md) Then we need to access the system state and make queries to receive views, so we require a **TodoListProjection** to handle TodoListListItemViewFindAllQueries returning a collection of TodoListListItemView and TodoListViewFindByIdentifierQueries returning a TodoListView.

## [Invoker](/recq-patterns/recq-component-pattern/invoker.md) In the end, we need a way to forge Commands and Queries accessible from the outside of a RECQ Architecture. To do this we need an invoker that exposes all the functions and implements logic (the Service Layer of the Layered Architecture). So we are gonna to define a **TodoListInvoker** generating payloads for every single TodoList-related command and query.

## [Service](/recq-patterns/recq-component-pattern/service.md), [Saga ](/recq-patterns/recq-component-pattern/saga.md)and [Observer](/recq-patterns/recq-component-pattern/observer.md) In this tutorial we do not need to handle cross-domain logic or do particular behaviour extensions, we will dedicate a specific tutorial to handle complex scenarios in RECQ Architectures. [Extend TodoList - Handle Complexity Tutorial](/getting-started/extend-todolist-handle-complexity-tutorial.md) ## Final Architecture

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.eventoframework.com/getting-started/todolist-recq-tutorial/recq-components-design.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.