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 objectsname
,physicaladdress
in billing context have modeled aggregate payer
:
payer
has properties/value objectsname
,paymentmethod
both recipient
, payer
aggregates separated context boundary. have own repositories.
questions:
is acceptable have multiple aggregates (provided in separate bounded contexts) using same "database table"?
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?
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)
Comments
Post a Comment