How to define domain entity model in frontend and backend?

I am studying clean architecture right now, and I have a question about domain entities. Suppose I am building a mobile application, there will be two types of services in my opinion.

• First type: Core business logic is built into mobile applications. The backend only works as a remote storage and communication channel between apps. For example, a simple todo-list app with a remote sync feature.

• Second type: Core business logic is built into the backend part. The mobile application is just a front-facing GUI. For example, a real-time collaboration service.

I am wondering what will be the entity for the frontend and backend. I came up with the following concerns.

• In the first case, entity model is defined by the frontend and the backend just follows it.
• In the second case, entity model is defined by the backend and the frontend just follows it.
• Use the same entity model for both the frontend and backend.
• Define separate entities for each of the frontend and the backend.

What will be the best practice to follow clean architecture? What will be the most concrete/clear implementation?

Or there is no separation of front/backend in architecture design?

You only have one entity model. The question is where you place it.

You can implement an application that contains everything from the ui to the database on a mobile device. In this case all circles of the clean architecture are on the mobile device.

 +---------------+
 | mobile device |
 +------------------------------------+
 | +------------+      +------------+ |
 | | ui layer   |      | DBRepoImpl | |
 | +------------+      +------------+ |
 |       |                   |        |
 |       V                   V        |
 | +-------------+     +------------+ |
 | | use cases   | --> | repository | |
 | +-------------+     +------------+ |
 |       |                            |
 |       V                            |
 | +-------------+                    |
 | | entities    |                    |
 | +-------------+                    |
 +------------------------------------+

You can also split the application an put the ui on the mobile device which makes requests to a backend application that implements the use cases, entities, repositories and so on.

 +---------------+                          +---------+
 | mobile device |                          | backend |
 +-------------------------------------+    +-----------------------------------------+
 | +------------+      +------------+  |    |   +-----------------+    +------------+ |
 | |    view    | ---> | contorller | --------> | rest controller |    | DBRepoImpl | |
 | +------------+      +------------+  |    |   +-----------------+    +------------+ |
 |           |           |             |    |           |                  |          |
 |           V           V             |    |           V                  V          |
 |          +-------------+            |    |      +----------+        +------------+ |
 |          |    model    |            |    |      | use case | -----> | repository | |
 |          +-------------+            |    |      +----------+        +------------+ |
 +-------------------------------------+    |           |                             |
                                            |           V
                                            |      +----------+
                                            |      | entities |
                                            |      +----------+
                                            +-----------------------------------------+

The sync feature you are talking about is just a special case of the first deployment diagram. You have a repository that stores everything locally. But you have also a use case that is periodically triggered in order to sync to a remote service.

Either way there is only one entity model.