Timeline for DRY polymorphic object creation (always valid)
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 2, 2021 at 1:48 | comment | added | plalx | I've always been a big supporter of always valid entities and small cluster ARs, but DDD tactical patterns don't seem to be a good fit here. | |
| Feb 2, 2021 at 1:38 | comment | added | plalx | Could you give an example. Imagine large CRUD document entities. There's a core bloc of data they all have. Then all documents have their own shape and behaviors according to the data they are composed of. For instance, an entity may be a PrinterRepairRequest where another could be an AccountPasswordChangeRequest. Requests have little in common except some core data & workflow behaviors. However, some rules may span across many of their data components making difficult to break the large clusters. | |
| Feb 1, 2021 at 20:52 | comment | added | Robert Bräutigam | I don't think so. Both of your solutions essentially just group the data, which the objects still need. I'm suggestion to move not just the data, but its behavior with it, so the polymorphic logic is not burdened by it. | |
| Feb 1, 2021 at 20:29 | comment | added | plalx | Wouldn't that be similar to my suggestion #2? In our situation it's a case management system where there's a multitude of concrete cases. We could have used composition instead of polymorphism I guess (e.g. Request--Type--DataSchema) where the type defines the data requests can have, but it seemed a little too abstract for now. | |
| Feb 1, 2021 at 20:02 | history | answered | Robert Bräutigam | CC BY-SA 4.0 |