Should this be a use case?
What is the Use Case as per Clean Architecture?
A use case is a description of the way an automated system is used. It
specifies the input to be provided by the user, the output to be
returned to the user, and the processing steps involved in producing
that output.
Those elements will be classes or functions or modules that have
prominent positions within the architecture, and they will have names
that clearly describe their function. From the use case, it is
impossible to tell whether the application is delivered on the web, or
on a thick client, a console, or a pure service.
Think about your step number two. Does it fit this description?
From your description, it looks like your second step matches with this part
...processing steps involved in producing that output.
where it played as one step of the Use Case.
So Use Case in your case would be all three steps that you mentioned.
But you want to know how to deal only with the second step right? Let's think about what are these steps according to Clean Architecture. How does Use Case work if it does not have (direct) access to the database?
Let's take a look at this definition of the "interface adapters" layer.
The software in the interface adapters layer is a set of adapters that
convert data from the format most convenient for the use cases and
entities to the format most convenient for some external agencies such
as the database or the web. No code inward of this circle should know
anything at all about the database.
Between the use case interactors and the database are the database
gateways. These gateways are polymorphic interfaces that contain
methods for every create, read, update, or delete operation that can
be performed by the application on the database. Those gateways are
implemented by classes in the database layer.
This sounds more closely to what you want to achieve. So what conclusion we can make from that? The implementation of the Use Cases uses gateway interfaces to interact with the database in the outer layer.
Here is one possible way of how pseudo code for your particular use case could look like:
@override
Confirmation processAndConfirmBatchOfEventsUseCase([
ProcessBatchOfEventsParams input = const ProcessBatchOfEventsParams(),
]) {
// Step 1: load the batch of events from service B
BatchOfEvents batchOfEvents = _eventsGateway.loadBatch();
// Step 2.1: transform the data from the database based on the batch of events
TransformedData transformedData = _dataGateway.transformData(batchOfEvents);
// Step 2.2: persist the transformed data back to the database
Confirmation confirmation = _dataGateway.persistData(transformedData);
// Step 3: send the confirmation to service B
return confirmation;
}
Regarding your next question:
How to call the transformation process.
It depends on the type of "transformation" you perform. If it is a simple operation it will be implemented inside a use case, if it is something related to the database then it will be another method taken from one of the available gateways. Do you think it could be a "mapper"? Take a look at the following chapter from the book (it is very short) and think if that aligns with what you are going to implement.
DATA MAPPERS
Going back to the topic of databases, in which layer do you think ORMs
like Hibernate belong? First, let’s get something straight: There is
no such thing as an object-relational mapper (ORM). The reason is
simple: Objects are not data structures. At least, they are not data
structures from their users’ point of view. The users of an object
cannot see the data, since it is all private. Those users see only the
public methods of that object. So, from the user’s point of view, an
object is simply a set of operations. A data structure, in contrast,
is a set of public data variables that have no implied behaviour. ORMs
would be better named “data mappers,” because they load data into data
structures from relational database tables.
Where should such ORM systems reside? In the database layer of
course.
Indeed, ORMs form another kind of Humble Object boundary between the
gateway interfaces and the database.
