CODEWITHSUNDEEP
databaseormarchitecturemigrationrepository-pattern
perber
perber

Reputation: 79

Hints to migrate to a new database and schema

In my company we are using a filemaker database, with builtin forms. (like in ms access) We would like to replace this database by micro services, written in PHP. Every micro service should have its own database.

As frontend we would like to use a Web App -> which communicates with the services via REST calls.

My question is, while we are working to replace the current system we must use the filemaker database. The filemaker database has a lot of redundancy and is not normalized.

I'm thinking about to use of the repository pattern. We could design our domains (not based on the current database) and a repository which writes into the filemaker database... Later we could replace the filemaker database through any other database, with a schema similar to the domain layer, but we must write the repository layer new.

The current database stores calculated values, where should I calculate this values, when it should been removed in future, I don't want to touch the domain layer again.

It would be nice to get some hints. How would you doing it? Maybe someone has experience with a similar problem.

Does the repository pattern fit for this kind of problem? Do we need to write our repositories from scratch?

Thanks in advanced

Upvotes: 0

Views: 41

Answers (1)

Rob Conklin
Rob Conklin

Reputation: 9446

You seem to be on a good path for this. Migrating to a service layer with the existing back-end, then replacing the database layer once you are done with the original application.

The repository pattern will be very appropriate for this.

For the calculated values should be part of the business domain layer. The business objects that you are saving to the repository should be complete (from a business logic standpoint). The repository will be responsible for mapping those business domain objects to data entities which get persisted, and writing to the relevant tables.

If you follow these patterns, the repository will be completely abstract you from the underlying database.

While you are doing this work, do yourself a favor, and don't create business objects that absolutely reflect the underlying table structure. Create objects that reflect the "correct" domain, not the one that has grown organically around filemaker screens. You already have a repository layer to abstract it, might as well take advantage.

Upvotes: 1

Related Questions