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.

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.

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.

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.

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.

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.

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...

Mud flowing into a project scope is a powerful image.

https://news.ycombinator.com/item?id=9061217

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.

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

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.

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.

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.

What are the established terms you prefer?

Are there any equivalences you'd like to highlight, involving other tried/proven terms everybody is likely to have heard of?

As far as I'm concerned, Evans, and Fowler (who he references in the DDD book), are the creators of the established terms. Feel free to demonstrate otherwise.

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.

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...

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

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