3

I've learned many ways to keep a domain model flexible over the years, but there is a remaining case where the setup resists change.

Suppose that we have kept our domain model properly isolated: we can change it easily. Now a change requires a fundamental restructuring of the domain model. There is one thing in our way: our persistent data structure will no longer fit the heavily-changed domain model.

In most cases, the data structure does remain usable, and may need only some minor adjustments. We can change our domain model, and then simply fix the translation to the classes that map to our data storage.

However, this is not most cases. Our data structure needs to change to accommodate the updated domain model. Let's also say we have a GB of data stored. (Should this be avoided to solve the problem? Definitely up for discussion.) After the change, we must still have that data, be it in its new form.

Particularly the updating of data to its new form seems to introduce an undesirable amount of work and risk.

How can we create a setup where the above scenario is easiest to manage? Particularly, it would seem good to minimize work and risk.

Feel free to apply whatever persistent data storage you deem most suitable.

Timo
  • 372
  • 2
  • 11
  • When you update the data model regularly, you will develop automatisms to minimize work and a process to minimize the risk which fit to your environment and your organization (or the organization of your clients). There is no silver bullet, this is simply a process of learning and improvement. – Doc Brown Feb 26 '20 at 10:35

1 Answers1

1

To minimize the amount of work and risk of updating the model and/or data, the best strategy I found is to co-locate data and its behavior. Also known as object-orientation.

For example, if you have some object with "properties" (i.e. a record or struct) and you read those out at some other place to do something with it (like persisting it), you are now very tightly coupled to that object. When something changes, you now have to essentially manually keep track both places. This adds work and risk, since things that change together aren't together. This is also why the Layered Architectures doesn't usually work well.

So, the model needs to know a little about persistence (and presentation, and so on), and be capable of executing a business case in it entirety, complete with persistence. If you do this, any data changes you have to the model will be localized to a single class. Risk is minimized because you don't have to manually track down where and how the data is used, work is minimized, because you have a single class to change.

Robert Bräutigam
  • 11,473
  • 1
  • 17
  • 36
  • Persistence awareness in the domain model? Controversial... I think this is too strongly opposed to everything I've learned for me to adopt this approach. Perhaps it does make this particular problem easier to solve. Although I don't believe this does anything to make the database changes safer or less work. – Timo Feb 26 '20 at 13:32
  • @Time Thanks for the honest reply. I agree this is controversial, since most of us (me included) learned exactly the opposite. It all comes down to being pragmatic and just trying it once or twice. I'm not saying it'll be easy, but once it's learned, these types of problems mostly go away. – Robert Bräutigam Feb 26 '20 at 14:35