Converting monolith app to multiple sub applications. How to migrate data from current app into the databases of various bounded contexts?

[David]

So like the title says I'm in the process of converting my one single monolith application into multiple sub applications.

Problem: I have one single database which holds all my data and I need to migrate this data to the databases in my various bounded contexts (7 or 8 of them). Each BC requires bits and pieces of data from the current database.

Are there any well known and proven ways to do this without a lot of manual work?

[Raoul Duke]

could you keep the single db and put views on it that split it up into bc's? to get things rolling, to work out the kinks? then move to truly independent ones?

[David]

There is no rush with this so I would prefer to just move to truly independent databases the first time around.

[Neil Hosey]

The problem with this approach is you have an existing data model and you are now trying to build a domain model on top of this. You need to take the time to find the boundaries of this data model and how it maps to each bounded contexts models. Using views to represent copies of data is a great way.

It can show you where you have coupling between 2 contexts. To break off a single contexta db you have to ensure you can handle events emitted by other contexts that would fill each view if they were tables, wherever you need views, is where this coupling exists.

[David]

I already broken my existing single domain model into multiple domain models, each in its own bounded context.

I have developed each bounded context as a standalone application which communicates with other bounded contexts using messaging.

The problem now is populating the database of each bounded context with the data from the current single database.

Some bounded contexts only have a table or two while others have 10+ tables.

At the moment the only method I can see is to manually export the data I need for a particular bounded context and manually insert it, having to change column and table names where necessary.

Doing it this way will take a lot of time.

[Neil Hosey]

Oh so your problem seems smaller than I thought.

You have your model per context but each context uses the same database. Whats not clear is if there is a single BC owner for each table in the database (ie avoid a shared kernel at db level).

If I was you my first step would be ensure there is a clear mapping between each domain model and the subset of tables in the db thst it is responsible for. I would ensure there is only one BC owner of each table in the database so that you could firstly uses db schemas to clearly define the BC boundaries in the db.

When one bounded context needs a copy of data from another, use views to replicate this at the start. When you are ready to move a bounded context to its own dh, replace these views with tables and allow the event handlers to populate these when handling events from other bounded contexts. You will obviously need an. Initial bulk insert at the beginning and go live is tricky!

[Peter Hageus]

So your new BC's/services aren’t backwards compatible with the existing single db schema?

Can’t see any other solution than database migration scripts in some form…

Syncronization of data from *other* bc’s should be done using your messaging solution.

/Peter

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[David]

Each context has its own database. What I'm trying to do is for each context, export the required data from the current database in the single monolith app, map it to the schema of the contexts database and import it.

I am trying to populate the database in each context, taking what I need from the current single database.

[David]

They aren't compatible. Since the application is old and is one single huge application there is one database which caters for all sorts of random stuff.

The schemas of my new bounded contexts are vastly different to the schema of the current single database.

I think I will just have to go with some migration scripts and manually mapping the data.

[Greg Young]

This prevents the possibility of running side by side and not doing a
big bang release which is quite risky as a strategy. But if you have
already done all the work its probably not worth going back and
rehashing a strategy.

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
Studying for the Turing test

[J Fernandes]

On a bit of a tangent, would it make any sense to try and use ES snapshot providers as a means to move away from the monolith database?

> email to dddcqrs+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
Studying for the Turing test

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.