Skip to content
Hallway
0:00 / 0:00

#dryprinciple#microservices#coupling

DRY Software Patterns & Microservices

Modern Software Engineering

265K subscribers • 8 videos on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • Presented by Dave Farley, founder of Continuous Delivery
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

62K views5 years ago1 recommendation

Software designDistributed systemsDesign patternsMicroservices and monolithsSoftware architecture

Dave Farley explores the trade-offs of the DRY principle in microservice architectures and how it can introduce tight coupling.

Probably the most popular advice to improve the design of your code is DRY - Don’t Repeat Yourself. It is good advice, a good general guideline even, but it is not always the best answer. This is particularly true in Microservices, where DRY can result in too much coupling between services. So when should you aim for DRY software, and when not? What is microservice that means that DRY is a problem? What are good guidelines for DRY in different parts of your system? In this episode, Dave Farley of Continuous Delivery explores DRY, Coupling and Microservices and how they interact. Dave takes a pragmatic software engineering approach to exploring the pros and cons of DRY on different scales and describes why the microservices example may be more complicated than it looks. ------------------------------------------------------------------------------------- 📚 BOOKS: 📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on Kindle ➡️ amzn.to/3DwdwT3 (Paperback version available soon) In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience. 📖 "Continuous Delivery Pipelines" by Dave Farley paperback ➡️ amzn.to/3gIULlA ebook version ➡️ leanpub.com/cd-pipelines 📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx 📖 "Building Microservices: Designing Fine-Grained Systems", by Sam Newman ➡️ amzn.to/31PyXOS 📖 "Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith", by Sam Newman ➡️ amzn.to/35IB8EO ------------------------------------------------------------------------------------- Also from Dave: 🎓 CD TRAINING COURSES ➡️ bit.ly/DFTraining 📧 JOIN CD MAIL LIST ➡️ bit.ly/MailListCD to get regular updates, advice and offers from Dave and Continuous Delivery! ------------------------------------------------------------------------------------- CHANNEL SPONSORS: Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0 Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/ SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across

Why it's here

1 person recommends this

What people say. Recommended for understanding the trade-offs between DRY code and coupling in microservice architectures.

u/FountainsOfFluidsin r/node • Recommends

On “How do you prevent duplicating this function inside every Microservice?”

Remember that we're talking about microservices here. DRY vs Coupling - link to this video The tradeoff for extremely DRY code is that if you update something in a util package, now you've got to update every single microservice that uses it. "The whole point of microservices is to allow for organizational scaling through de-coupling." You've got to make the judgement call, and in my opinion a small, simple snippet of code like the jwt.verify is very unlikely to need to change, and therefor the coupling is not worth the DRYness.
14View on Reddit

u/PM_ME_YOUR_DOOTFILESin r/programming • Mentions

On “Software Development Is Misunderstood ; Quality Is Fastest Way to Get Code Into Production”

link to this video This is a pretty good video outlining the trade-off between coupling and dry and how it relates to Microservices. Tldr: dry is a guideline like you suggesting. Too much DRY on the architecture can lead to disastrous coupling with services calling each there and cancelling the benefit of Microservices.
2View on Reddit