Q&A
1) Is it acceptable to have multiple aggregates (provided that they are in separate bounded contexts) using the same "database table"?
- It is acceptable to me as long as you follow a strict strategy for managing the shared state.
- It is acceptable to DDD, since the domain is considered more important than the data.
- It is acceptable to your customer as long as it gets the job done without introducing (too much) hidden costs.
2) Customer data would likely be needed in many more bounded contexts. Would this not mean many aggregate, repository and factory implementations for each bounded context? There will be a degree of redundancy in code. Does this not effect maintainability?
Not necessarily, have a look at the shared kernel pattern.
3) Is it acceptable to have shared properties across aggregates? An example would be the customer Name property. This would also mean redundant validation code?
Same answer as question 1. Concerning redundancy, once you have a shared kernel you may simply put your validator classes in there.
About your conflict between DRY and DDD:
Elegant code does not unnecessarily put great design principles at odds with each other. Usually there is a way that satisfies the principles. You simply haven't found it yet, because either you don't understand the principles enough or you haven't dissected your problem enough.
(if this sounds dogmatic that is because software engineering is actually a religion)