🗞 Stream Recap: Loosely Coupled Architectures
Engineering Culture #14
Hey, this is Denis—small update on the structure of these posts: the recaps will from now on arrive in separate emails from the announcements as I found it to be too confused and coupledhah!. I’m experimenting with this as I don’t want to spam you needlessly with routine matters outside of the scope of articles.
The teaser for this week’s stream will land in your inbox later today and going forward I’ll be preparing them more in advance so you’ll get a combination of recap-announcement-recap-announcement split 3-4 days apart on a regular cadence. As I said this is an experiment where Im trying to smooth out the rough edges. Let me know what you think!
Talking Points
What is coupling, why do we need it and how can it be measured / graded with connascence?
“Can you spot coupling in the design phase?”
“Is GraphQL beneficial for loosely coupled architectures?”
“Is there a method to get in loosely coupling mode when you have a big legacy BigBallOfMud? What to do in what steps? Do you wanna talk about it?”
Different types of application-level coupling: front-, back-end, middleware, infrastructure, mobile
Downstream consequences of bad coupling on the team and delivery speed
Continuous delivery and testing autonomy
Technical debt: the timing and investment of refactoring and decoupling
Adrian’s Step 1: Federator / Gateway to decouple your network layer
“Decouple” by cleaning a Big ball of mud with refactoring and dependency inversion
What is the strangler fig strategy?
Introduce communication infrastructure for services that are too strongly joined
Microservices vs. Modular monolith
Testing and deployment pains are a signal of a architecture modeling problem
Coupling to time and execution order
Treat your big-ball-of-mud monolith like an instrument. Learn patterns that you can play on it.
Database identity coupling is one of the worst type of coupling. Usually caused by ORMs
Remove implicitly coupling inter-process communication via a shared SQL database
Denis: Growing from small MVP monolith to 80+ microservices at Firstblood
Differences between request/response coupling, message queues and temporal coupling
A brief tangent of event sourcing vs. event-driven message systems
Colourless vs. coloured programming languages (ie. sync, async, promises, goroutines)
Mentioning Yves Goeleven: Most features can be built using 9 simple architectural patterns. Tight coupling limits you to 4.
Recordings
Highlights (AI)
Architectural Decision-Making and Best Practices
💡 Architectural decisions are crucial in loosely coupled architectures as they affect the choice of technologies and features to implement, making it easier to build the system the right way.
🏗 Mentoring and coaching younger developers on the importance of decoupling and design principles, such as coupling and cohesion, is crucial for building loosely coupled systems.
🤔 The preference for microservices with containers is based on the flexibility and ease of use for developers of all levels.
⏰ Developers often choose to refactor later, but this decision is actually a trap as refactoring later is always more expensive, highlighting the importance of early and ongoing refactoring.
🚧 To prevent connasence of identity and improve system architecture, only one service should be responsible for retrieving objects from the database and communicating with other services through a message bus or secure API endpoints.
🔄 In a decoupled system, the backend doesn't know the format of the output needed, allowing the front end to decide and orchestrate the micro frontends.
📱 GraphQL is particularly useful when different platforms (Android, iPhone, web) have slightly different querying needs, allowing for a more flexible and efficient solution.
Migration Strategies and Techniques
🔄 The Strangler fig migration pattern is an effective way to decouple systems and transition from old legacy systems to new ones seamlessly.
💡 Strangler fig implementation is an advanced tactic for breaking apart a big ball of mud in software architecture, and it is recommended to tackle the problem without paying remediation costs.
💡 The process of achieving a loosely coupled architecture involves starting small, moving fast, and eventually cleaning up the big ball of mud.
🏗️ When migrating to a new architecture, it's crucial to have a clear goal and understanding of the desired outcome, as well as the ability to gradually migrate different components, such as front-end and back-end, piece by piece.
💡 The success of a system depends on decoupling aggressively and preventing tightly coupled parts from hindering progress and iteration.
Cultural Transformation and Organizational Change
💡 Implementing continuous modernization and transitioning from legacy systems to new ones requires not only technical changes but also a complete restructuring of the company culture and ways of working.
💡 The old way of working, where software was built and shipped as a static product, needs to be replaced with the mindset of continuous delivery in order to adapt to the age we're in.
💡 "Knowing how to decouple yourself from a mess, your solution will grow, it will grow your solution out of the monolith very if it's successful if it's. If your business is successful. The code will grow and will become a mess yeah."