DDD Validation best practice: entity containing data doesn't have the context to validate before data is set. Where should set function be?

Question

I am pretty new to DDD, so bear with me.

I have a Chat room and people in the Chat room. The people in the chat room need to propose a date they would like a webinar to be on. we have a bussiness rule, where we need to have at least 3 people in the webinar for the webinar to take place and each person interested in the webinar needs to say that they are ready for someone to propose a date

I have 2 solutions in mind

solution 1:

Making Chat room the aggregate root

Have a function propose date on the Chat room, ProposeDate(Person, Date).

In this solution I would validate the bussiness rules on the Chat room and set the date on person entity.

An issue With this solution is that we have a setter on the person entity that can be called from anywhere in the domain without the reference to the validation in the chat room, should the proposed date for each person actually be removed from the person entity and be set on the chat room itself so it cannot be set wihout calling chat room entity?

solution 2

Make person the aggregate root

On Person have ProposeDate(Date).and person would ask Chat room can i propose this date. The problem i have with this solution is I believe it invalidates the tell don't ask principle.

If i have it all wrong and there is another solution please let me know.

The people have to propose/accept/reject that date dates to each other.

Answer 1

When you have a situation like this where two objects seem interdependent, sometimes the solution is to refactor a dependency into third object. In this case why don't you have WebinarVote object with propose(ChatRoom, Person) method?

After the voting period is over, your Webinar (or whatever it is called now in your architecture) service object will iterate WebinarVotes to determine which webinars take place and which are not.