February 2009
Beginner
222 pages
5h 23m
English
Content preview from 97 Things Every Software Architect Should Know
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.
Chapter 48. Don't Control, but Observe
Gregor Hohpe is a software architect with Google, Inc. Gregor is a widely recognized thought leader on asynchronous messaging architectures and service-oriented architectures. He coauthored the seminal book Enterprise Integration Patterns (Addison-Wesley Professional) and speaks regularly at technical conferences around the world.
—Gregor Hohpe
TODAY'S SYSTEMS ARE DISTRIBUTED AND LOOSELY COUPLED. Building loosely coupled systems is a bit of a drag, so why do we bother? Because we want our systems to be flexible so they do not break apart at the slightest change. This is a critical property in today's environments, where we may only control a small portion of our application, the remainder living in distributed services or third-party packages, controlled by other departments or external vendors.
So, it looks like the effort to build a system that is flexible and can evolve over time is a good idea. But that also means our system will change over time. As in "today's system is not what it was yesterday." Unfortunately, this makes documenting the system challenging. It's commonly known that documentation is out of date the moment it is printed, but in a system that changes all the time, things can only be worse. Moreover, building a system that is flexible generally means the architecture is more complex and it's more difficult to get the proverbial ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access
More than 5,000 organizations count on O’Reilly
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.Julian F.
I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.Addison B.
I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.Amir M.
I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.