When implementing a domain with CQRS, domain-driven design and event sourcing, is it worth the effort creating a command, an event, an aggregate and a command handler for commands with little to no domain logic e.g. if I have a requirement to say, create a group, where perhaps the only requirement is to ensure the group name is not empty, is there a need to have a Group aggregate, a CreateGroup command, a GroupCreated event and a CreateGroupCommandHandler in this case?
Even when the domain is light on logic, so to speak, the value that comes with modelling aggregates (in-memory persistence, constraints management etc.) and events (intent modelling, business transaction log + audit log, integration etc.) still apply. Additionally, the reasons for modelling command messages separate from event messages still apply (it's about the intent of the message and they can evolve independently). More-so, a domain light on logic, so to speak might not always remain so.
I think it might be possible, however to not have an explicit class representing the command handler. The command to aggregate mapping could be done in some other way.
However, for cases where the domain does not manage the constraints e.g. in the case where the events really are implicitly-external e.g. if the groups are managed elsewhere and simply need to be replicated to our domain, it should suffice to have only an event.