Applying Clean Architecture Principle When Add Dashboard module witch query multiple services from Application Layer

I am asking about the best way to add dashboard module to application software without violating the SOLID principle and clean Architecture principle in general.

My first though is to add layer(Dashboard layer) with is responsible for gathering all statistics from the application layer,
but what I notice is Dashboard layer will have more than one reason to change which violate the SRP, in other word the Dashboard layer will be affected by:
1- the dashboard main user (manager) new requirements which is expected.
2- the users of the other modules which we gather the statistics from e.g. Registration module.
as a result, any change from the manager or the Registration module will affect the dashboard layer.

A quick response

If I understood what you need to do is a Reporting module which will need to read some data of your application.
What you call Dashborad layer may be just a new module that you want to add to the application.

Some developers will go quickly to introduce a new Application which will be a Reporting tool of the main one.
Which is not bad idea, but what if all what you need is just 1 or 2 dashboards ?

I advise you to start by introducing a new module in your Application.

1. It is not a part of the Domain.
   What you are doing is not a new part of the domain. May be you are handling many domains in the application and this dashboard need to access all
   the data of all these domains.

2. It is not a part of the infrastructure because it is not a dependency.

3. => It is in the other side.

This module is like a new Backend for future Front Application of your dashboards which will consume your data.

The responsability of this module is only agregating and may be transforming data.
If you fill that this kind of thing may be done in the Front Application that display dashboards, let's go and start doing it like that. (if consuming the existing Api that you already have fill your need, and time response fill your need)
Do not imagine some requirements that are not yet present.
And when you feel that things are changing and you need to introduce a Backend for this reporting tool go for it.
May be it will responsible to make this kind of aggregation, may persisting data to make reading them more optimized...

The conclusion that the requirement that you have is like a Query Module of your application.
It doesn't have any relation with the domain of the Application.
It will be nice to make this part a clear part in your Architecture without going quickly to create a new Application.
And when you feel it is time to separate it, do it

You are mixing different concepts here. A Layer contains several modules (not just one). They'll all have similar responsibilities. For example, the View layer in MVC contains View modules.

You need to break down your requirements into smaller ones before starting to Model it out adequately.

For example, one requirement could be: Admins can Add Reports.
For this requirement, you'll need an Admin Entity, a Report Entity, and an Application Service that Adds report.

I find that when I do DDD, there's a natural Layer architecture that'll develop from my work but DDD and Layers are not mutually exclusive.

Even the dashboard will show a lot of different things, each of the things is not the responsibility of the dashboard. The dashboard is responsible for placing the different items at different locations and the management of this layout. The items must use a plug-in mechanism to hook into the dashboard.

It depends on the technologies you use how those plug-in mechanisms are implemented, but the general structure is always the same. You must inverse the dependencies from the dashboard to the different items.

I usually use the term "view site". A view site is a location where a view can be installed into. The dashboard will define view sites for the locations where other modules can install views into. I call the class that is responsible for defining view sites a "view layout". The dashboard must use a lookup mechanism to find "view site contributions". view site contributions are the plug-ins that plug into a view site. After the dashboard has discovered all it calls each "view site contribution" and passes it a view site. Usually each "view site contribution" has an identifier and the dashboard only knows that identifier A should be installed at view site B. This is what I mean when I say the dashboard's responsibility is the management of the items it displays.

I recently published a git repository that is about this topic. The example is done in Java Swing, but the concept behind it can be applied to any other technologies too - I guess. Maybe I will publish an React based example in the future.

If you are using web technologies you might also be interessted in the book "Micro Frontends In Action" by Micheal Geers.