Let's say we have a legacy database. We find out the Orders and OrderLines tables contain each 100 columns. Some of them cannot be null, they are not and will not be part of our business logic but they need to be initialized. Also there will be another set of columns we will not use either.

Now we want to start building a domain model on the top of that. We realize many of these columns or attributes do not belong to our ubiquitous language. Which would be the correct to model the requirements and at the same time satisfy the legacy database ones?


1 Answer 1


You will need two sets of requirements: the ones for the new system and the ones for the legacy system. The requirements for the new system will be modeled on top of the ubiquitous language, which doesn't include the legacy fields. In order to satisfy the legacy requirements you will have to implement a legacy layer, somewhere between the business logic and persistence, that intercepts the saving of current domain entities and decorates them with the legacy fields (only the ones that need to be initialized). The layer will then continue with saving the decorated entities, which are now in correspondence with the legacy database.

You could implement the legacy layer inside the database, through triggers, but it will not be easy to maintain and/or debug.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.