repository pattern - Bounded context implementation and design -

let's have 2 bounded contexts, shipping context , billing context. each of these contexts need know customer.

at data level, customer represented customertbl table in database. table consists of necessary columns describe customer.

columns in customertbl (simplified):

• name
• physicaladdress
• paymentmethod

the shipping context concerned name , physicaladdress while billing context concerned name , paymentmethod.

in shipping context have modeled aggregate recipient:

• recipient has properties/value objects name , physicaladdress

in billing context have modeled aggregate payer:

• payer has properties/value objects name , paymentmethod

both recipient , payer aggregates separated context boundary. have own repositories.

questions:

1. is acceptable have multiple aggregates (provided in separate bounded contexts) using same "database table"?

2. customer data needed in many more bounded contexts. not mean many aggregate, repository , factory implementations each bounded context? there degree of redundancy in code. not effect maintainability?

3. is acceptable have shared properties across aggregates? example customer name property. mean redundant validation code?

q&a

1) acceptable have multiple aggregates (provided in separate bounded contexts) using same "database table"?

• it acceptable me long follow strict strategy managing shared state.
• it acceptable ddd, since domain considered more important data.
• it acceptable customer long gets job done without introducing (too much) hidden costs.

2) customer data needed in many more bounded contexts. not mean many aggregate, repository , factory implementations each bounded context? there degree of redundancy in code. not effect maintainability?

not necessarily, have @ shared kernel pattern.

3) acceptable have shared properties across aggregates? example customer name property. mean redundant validation code?

same answer question 1. concerning redundancy, once have shared kernel may put validator classes in there.

about conflict between dry , ddd:

elegant code not unnecessarily put great design principles @ odds each other. there way satisfies principles. haven't found yet, because either don't understand principles enough or haven't dissected problem enough.

(if sounds dogmatic because software engineering religion)