Timeline for Introducing behavioural differences in a complex domain model
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 3, 2017 at 20:21 | history | tweeted | twitter.com/StackSoftEng/status/827613090644652033 | ||
| Feb 3, 2017 at 6:26 | vote | accept | markus | ||
| Feb 2, 2017 at 19:10 | answer | added | Frank Hileman | timeline score: 2 | |
| Feb 1, 2017 at 17:05 | answer | added | VoiceOfUnreason | timeline score: 1 | |
| Feb 1, 2017 at 16:09 | comment | added | markus | @plalx cont'd And now we are trying to figure out a way of allowing non-aggregate domain models to change their behaviour depending on the kind of root object. Regarding your second comment: E.g. a Loan is only valid if its contractual parties are of a certain type ==> E.g. ConsumerLoan must not be associated with a company as creditor whereas a InvestmentGoodsLoan must have a company as creditor. | |
| Feb 1, 2017 at 16:06 | comment | added | markus | @plalx no Loan is not the only aggregate root (but the one I am working on:-)) We have e.g. BusinessPartner as another aggregate root. I agree with your comment about getLoanRoot(). I am looking at a relatively large codebase with a relatively procedural/anemic/... business model. A lot of business logic was placed outside the model in services classes (including lots of switch or if/else constructs). Then came a shift towards moving logic (e.g. validation rules) to the domain classes. | |
| Feb 1, 2017 at 15:26 | comment | added | Constantin Galbenu | You could refactor your code by applying "Replace Type Code with Subclasses" tehnique, as stated here: sourcemaking.com/refactoring/replace-type-code-with-subclasses . Anyway, those switch statements increase the CRAP index and you should get rid of them | |
| Feb 1, 2017 at 14:07 | comment | added | plalx |
By behaviors I mean business use cases that have to be fulfilled as well as the business invariants that apply. For instance, in which process you need getAllowedTypes?
|
|
| Feb 1, 2017 at 13:59 | comment | added | plalx |
"sucking the domain logic out of the individual domain objects" I really don't get why it would have to be like this. Do you have concrete examples of behaviors? Is Loan your only aggregate root? It may be possible, but large aggregates are usually a sign of erroneous designs that do not align well with the business realities. The fact that you even have a getLoanRoot method is suspicious.
|
|
| Feb 1, 2017 at 13:10 | review | First posts | |||
| Feb 1, 2017 at 22:48 | |||||
| Feb 1, 2017 at 13:08 | history | asked | markus | CC BY-SA 3.0 |