Re: Is it "allowed" to access a database in a BC from the outside?

Markus Gaertner <[email protected]>
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <CALO_cXYOjFKNGVY8g67y4TBbKOof7g06UQnhpOox4m58_DWrVA@mail.gmail.com>
Hi Atle,

I would probably try something like twitter did when moving over to
cassandra. Start with writing to both systems, but still reading from the
old system only. Then see what happens, what you didn't anticipate. Then
gradually start moving more and more pieces from the reading part over to
the new system which adheres to ports&adapters, provides a clearer
structure, and so on. In the end, you will have replaced the old system
with a new one.

I would think about the different bounded contexts there, and probably
split the migration from old to new system by BC.

Best
Markus


On Wed, Apr 10, 2013 at 10:18 AM, atle03 <[email protected]> wrote:

> Hi all,
>
> Anyone out there having experience on integrating a modern, DDD-style app
> with a legacy system?
>
> We are planning to slowly start to replace our legacy system with a set of
> smaller bounded contexts written DDD style. (This also means switching from
> legacy development technology to more modern tools - .NET in this case).
> The legacy system is very DB-centric, and will (because of the business
> value of its code base) be with us for a long time yet. This gradual
> replacement can be seen as a way of using Martin Fowler's strangler
> application pattern (
> http://martinfowler.com/bliki/StranglerApplication.html). An important
> note is that the legacy DB contains (almost) no stored procedures, just
> plain data.
>
> The strategy we have chosen is to let the new bounded contexts use
> (subsets of) the same database as the legacy system. This means that the
> repositories in each "new" BC will work towards a subset of the db tables
> used by the legacy system (they store their data in the same tables).
> Technically this seems to work well, but I am a bit concerned if there are
> more long-term aspects of this that we haven't thought about.
>
> Speaking in DDD terms, I guess we should see the common database as an
> shared kernel upstream to the new bounded contexts, and treat all db
> changes correspondingly. The repositories in the new bounded contexts will
> in addition to being a repository also act as an anti-corruption layer
> towards this shared kernel. But even with an ACL, we still have to pay
> special attention to database changes, since we cannot just compensate for
> everything in the ACL. Over time, more and more logic will be moved into
> the new bounded contexts, but for all foreseeable future the legacy will
> exist and some business processes will be implemented there.
>
> Anyone out there with any experience they want to share?
>
> Regards,
> Atle
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development
Agile Team Academy, September, Amsterdam http://www.agileteamacademy.com/

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.