On Clean Architecture, how draw borders on methods for an entity, and should entity have conditional logic?

part 1:

if I have an two entities

1. User
2. Post

Should User entity only encompass methods that pertain to User Obj?

• createUser, deleteUser, getUser, listUsers, updateUser, ...updateSpeificOnUser?

What happens in the relationship of User can make Posts. do these additional method reside into User?

• createPost, deletePost, updatePost

or should it be remain in Challenge entity - to be completely agnostic of which actor will call these actions.

Then in Use-Case layer, to make a conditional that checks the following

---

INPUT --> userId, postContent

---

1. check getUser(userId) exists and their 'authorized titles' - otherwise throw error
2. Evaluate whether credential is authorize to make this specific post. - otherwise throw error.
3. calls post.create(userId) with user credentials. - otherwise throw error

---

OUTPUT --> return postId | 'error message'

---

part 2:

in the above use-case shows the business logic that checks conditions and entities for authentication and authorization to make that user action. Is this exactly where conditionals should reside? because I can also picture moving conditions inside entity methods.

for instance post.create may take a second argument (userId, userTitle) the title may contain 'vip-user' which are allow to create post, as opposed to 'unpaid-user'. If I have this condition in the entity level, then in someways, I do not need step 2.

The begs the question, where should I put these conditions ? If I were to answer my own question, maybe theres no right answer but it depends on the requirement of the policy. Having conditions in the entity level means it's a critical business logic, and any use case will have to abide to such rules. On the other hand, relaxing the entity conditions, it allows for use-cases to adapt for various use-cases. And since use-cases are still application logic, enterprise logic are just more reusable logics tailored to its boundaries/constraints.