In a discussion I got the following question. In a banking domain there is a aggregate root, Account, identified by Account Number. Assume at some point in time the bank has decided to change all the account from 8 digits to 12 digits due to some reasons and the account is accessible with both the numbers for a year and after that only new number will be used, how this should be handled in a DDD way, I was wondering whether it will create a new bounded context
Asked
Active
Viewed 593 times
1
-
1Bounded Contexts typically have their own Ubiquitous Language, their own vocabulary. Changing the number of digits in an identifier hardly requires a new language. – guillaume31 Nov 16 '17 at 10:11
1 Answers
4
With an entity you always want to have a technical id i.e an Id (UUID) property that's immutable and that your app controls. The natural id AccountNumber is a Value Object only. Basically, in your app for technical reasons only use the Id, the AccountNumber is just another VO/detail of the aggregate.
Changing the account number format shouldn't create a new bounded context, it's just a change inside a Value Object. But all the problems you have because of the change, stem from the implementation, not from the domain modelling (unless it's a wrong model :D) . If you're using Event Sourcing and CQRS, things should be simple enough, relatively speaking. If you're using an ORM who restores state, things will be more complicated.
The DDD way means you have to understand the nature of concepts, the actual implementation depends on many things.
MikeSW
- 16,140
- 3
- 39
- 53
-
In what ways using event sourcing makes it easier than with current persisted state? – plalx Nov 16 '17 at 15:49