Refactor domain-specific fields out of generic DDD models.

[tclasen]

https://github.com/jddw-dev/booking-ddd/blob/f2d6694ee69d5fec343ca45c98130f9fcd8af40c/src/libs/ddd/command.base.ts#L21

Since these are generic models (I'm only referencing commands here, but the same would apply to every class within this folder) they should only contain the common attributes you would expect for a valid command (and other) data structure within your system. Domain specific fields such as a booker should only be present in domain specific commands co-located with your domain specific aggregates.

Examples:

• RegisterBookerCommand within your auth generic domain
• NewBookingCommand within your booking domain

Each of these would make sense to contain both the common metadata as well as the bookerID field (maybe more?)

[jdutheil]

Oh yes, for this one I mainly follows what was done in other repositories I get inspiration from, thinking that I might need this information sometimes to log who did what. But I guess there is in fact a better way, and understand the separation of concerns we need between the domain and the more generic stuff.