Hello.
First of all, its hard to tell that you should or shouldn't use DDD. It depends and you need to figure it out by yourself.
To help answer that question, you need think about your business logic.Does it contains a lot logic? For example,
If you schedule an appointment what should happened?
Send mail to participant.
Does someone need to approve an appointment?
Does someone could reject it ?
Maybe he can send an request for new date, because he is busy it that time.
Maybe after an appointment are approved by all participants, new document "MeetingNotes", are created in local intranet.
All of this is kind of domain policy. You can replace it with any new policy, and core application is intact.
One of benefits making DDD is that you could easy unit test some logic in your application.
Definitely, you want to test policy.
If you haven't complicated domain, it's probably better to stick with CRUD. Trust me, hours of development saved. In all you need to have working product.
I recommended to read some articles, there are plenty of them in web.
https://martinfowler.com/bliki/BoundedContext.htmlDefining bounded context is one of hardest question in DDD, so answer could not come so easy.
Hope, i help you.
Best regards, Rafał.