Is it a good idea to implement CQRS Read model as an Aggregate?

Is it a good idea to implement CQRS Read model as an Aggregate?

Not really?

An AGGREGATE is a cluster of associated objects that we treat as a unit for the purposes of data change.

Since queries don't change the data, an aggregate is unnecessary ceremony. Putting a bunch of business data into an object just to take the data back out again doesn't make a lot of sense. Using a POCO/POJO/plain data structure gets the job done.

In general when using CQRS you also use an event sourced design, so you don't have DDD entities (and by extension aggregates - at all). Usually when using CQRS, you usually have a "command model" & a "query/read model" where the "command model" is some event queue that you may "snapshot" every X amount of time; and your query model(s) are just use case optimized search data stores where you aren't really interested in modelling a whole aggregate.

Now, even if you aren't using an event sourced system, and you are using DDD with just several "query/read models", chances are you want to create a DDD model and have aggregates on the "command model" and not the "read model", as your "command model" represents your domain view & understanding of your domain reflecting your (DDD) ubiquitous language. The read/query model(s) are more oriented towards fine tuning performance for particular use cases (fast searches in a product catalog for example); or for enriching/aggregating data with other "external-bounded context" information.

As a side note, it is important to note that even though your query/read model is not intended to match 1:1 your aggregate, there is usually some correlation between your command aggregate, and your model DTO.