Shared Entities in Clean Architecture - flutter

Question

I'm reading into clean architecture and I want to apply it to some software that I wrote. In this software, entities such as User and Group play a very central role. For this reason, it would make sense to share these entities across the code in order to avoid repetition but it is somehow also against the rules of clean architecture.
What is the right decision to be made in this case? Should I just throw in a "shared/entities" folder in core?
The project that I am working on in programmed mainly in flutter, if that's important to the answer.

Answer 1

I know zero about Flutter or Dart (apart from what I just Googled), but it looks like it supports interfaces.
A good approach is not to throw users and groups into a shared folder, but to create some really light-weight representations of them, and throw those into a shared folder / common library. An interface is a great way to do this because in the interface you can specify the important basics that parts of your application need to generically know about, without adding implementation specific baggage and dependencies.
When designing your interfaces, be sure to be aware of principles like SOLID - especially the Interface segregation principle (the I in SOLID).
To elaborate a bit more:
Define IUser interface
Have your User class implement IUser
Have someway of instantiating IUser using your implelentations, like User.
Where your application references User - switch this to use IUser.
Update in response to comment
My usual starting point architecture would be to define DTO's which I share across all layers of the app (UI, Biz Logic / Data Access), basically like what I think you're suggesting. For me, DTO's are as light-weight as possible - basically information carriers. These are shared across all layers, in a common package, as per clean architecture so that different layers of the architecture (e.g. biz logic and data access) are not tightly coupled to each other.
However, users can be bit of a special case in that they can have security / identity / credential related stuff which can become quite specialized and/or implementation & technology specific. This, I suspect, is partly where #duffymo's comment about tight-coupling comes in.
With my answer I'm basically saying that, yes, you can put DTO's into a common folder - and for tricky cases (like Users) you always have the option of defining interfaces on them as well... e.g. the User DTO might have properties which are interfaces rather than concrete properties.
class UserInfo
{
string FirstName { get; set; }
string LastName { get; set; }
ITaxData TaxData { get; set; }
}
I admit it's entirely possibly I'm over-complicating things with the '(some) DTO properties as interfaces' idea.