
Domain Driven Design When Surrounded by Legacy Development (2013) [pdf] - brudgers
http://domainlanguage.com/ddd/strategy/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
======
vinceguidry
I have to deal with a large, legacy Rails app, my strategy is to cordon it off
and treat it with kid gloves. In this case it's quite literal, my main work
machine cannot run a development server or even deploy the codebase. Instead I
use a separate laptop. 95% of my time is spent building an external
architecture with the eventual goal of pulling out successive pieces of
functionality from the main app until nothing is left. When things are planned
I push hard for building on the external architecture rather than extending
the legacy app.

When I first got to the job I thought it might be worthwhile to refactor and
upgrade the old codebase, but eventually settled on the cordon strategy
because it's ultimately more flexible, and not having to touch the production
site every day gives me a lot of peace of mind.

Anyone in this situation, I would recommend re-implementing your Active Record
models with an external database connection using Sequel or even just regular
SQL queries. I have a giant query with a crapload of joins that can retrieve
product data, it's among the very first things I built at this job.

This provides a nice base to build on, the database is the heart and soul of
the business, and it is far easier to work at that level of abstraction rather
than trying to mess around inside the codebase.

~~~
marktangotango
This is heresy and unbelievers will be punished! Seriously though, I agree
whole heartedly and am often dismayed at the lengths developers will go
through to not write sql.

~~~
vinceguidry
Oh believe me, I tried to use Sequel to get that data. After I realized just
how many joins and how many layers of abstraction I'd need to debug the damn
thing through, I knuckled down and built the query. Even so it runs behind a
caching layer. Thankfully, I don't need up-to-the-minute product data.

~~~
marktangotango
At one previous gig we had a product-god query similar to what you're
describing, which was the source of neverending sorrow. Eventually, the
solution was to write and schedule a stored procedure that built a
'current_product' table with essential fields. Products and catalogs weren't
updated that frequently, so it ran nightly, or could be run on demand.
Performance increase was immense.

~~~
vinceguidry
My problem was that there was so much baked in logic that I had to trace
through the codebase to figure out, and even so, I was getting lots of
incorrect results for months until I'd worked all the issues out. Even now
sometimes my boss will be like, "there's bad data in the feed, can you check
the query?" Most of the time it's bad data, but every time I have to load the
damn query up in SequelPro and make sure it's doing its job. I dread the day
when I actually have to understand what it's doing again.

------
yuchi
Not only I’m discovering a lot of jargon that I should have known before, but
also this document is giving me formal knowledge for the project I have
currently at hand.

To the op and the author, my most sincere thanks.

~~~
brudgers
I was thinking user _zgm_ 's comment [1] in the current Ask HN regarding large
code bases and it reminded me of this InfoQ talk by Evans and Foote:

[http://www.infoq.com/interviews/eric-evans-brian-foote-
desig...](http://www.infoq.com/interviews/eric-evans-brian-foote-design-
discussion)

Mud flowing into a project scope is a powerful image.

[https://news.ycombinator.com/item?id=9061217](https://news.ycombinator.com/item?id=9061217)

------
evtothedev
I have been re-reading Domain-Driven Design bit by bit on the train each
morning and nearly every day I find something I can immediately apply.

Bonded contexts, for example, immediately clarified how to establish naming
conventions across micro-services.

~~~
cpeterso
The Domain-Driven Design book is awesome, but a bit heavy. InfoQ published a
nice introductory book called "Domain Driven Design Quickly". A free PDF is
available, too:

[http://www.infoq.com/minibooks/domain-driven-design-
quickly](http://www.infoq.com/minibooks/domain-driven-design-quickly)

------
velox_io
I have seen the proxy pattern being used before. It's quite nice as it create
a foundation that you can build on. Requests can either be sent to the legacy
system(s) or redirected to the new system (for new functionality/ fixes).
Working with incremental changes, rather than trying to replace the whole
system thing at once. The tricky part is dealing with more data silos.

No one sets out to create a legacy system (maybe some consulting companies
do), they just get more complex/ scary overtime. As the codebase and layers of
technical debt are added, while documentation and the original creators
disappear.

I'd love to know the economic cost of businesses held back by legacy systems
each year.

~~~
brudgers
Just to clarify, one of the points that Eric Evans makes in the article is
that programmers should set out to create legacy systems, because that means
that they are really good at solving the business problems they are supposed
to solve for a really long time.

I used to think that an open source project that hadn't been updated since
2002 was inherently bad. Now I've realized that sometimes this means that it
is just done and it's so simple that everything that has changed over the past
decade is addressed by ./configure and make.

------
ExpiredLink
Evans re-invented many tried and proven concepts and gave them his own names
which lead to much confusion. I prefer not to use his idiosyncratic
terminology and stick with the established terms.

~~~
xdl
Can you expand upon this? I was recently introduced to DDD and had the same
gut feeling, although am having trouble articulating exactly why. It does feel
like a lot of what Evans is saying has already been said in design patterns
books.

~~~
ExpiredLink
E.g. Repository. It's clearly similar to other persistence designs. OTOH, it's
somehow different from plain ORMs - and it has a different name.

[http://stackoverflow.com/questions/25648676/ddd-
repository-u...](http://stackoverflow.com/questions/25648676/ddd-repository-
unit-of-work-orms-and-dependency-injection)

~~~
brudgers
That doesn't feel strong enough to support the claim that Evans is repackaging
established terms.

~~~
ExpiredLink
Don't be so lazy. Take any of the DDD concepts
([http://en.wikipedia.org/wiki/Domain-
driven_design](http://en.wikipedia.org/wiki/Domain-driven_design)) and try to
find the equivalent real-wold names.

