Step 2: Draw a Rough Architecture
From my experience, it’s essential to be able to draw the core of your architecture. This helps others understand what you are thinking, but it also helps you think through your ideas. There is really no better way to explain your ideas to your colleagues than using a whiteboard.
You don’t need to get it right, and you don’t need to make it complete. What you do need to do is break your architecture into pieces that make sense. The nice thing about software architecture (as compared to constructing bridges) is that you really can replace entire layers cheaply, if you’ve isolated them.
Start by choosing the core problem that you are going to solve. Ignore anything that’s not essential to that problem: you will add it in later. The problem should be an end-to-end problem: the rope across the gorge.
For example, a client asked us to make a supercomputing cluster with ØMQ. Clients create bundles of work, which are sent to a broker that distributes them to workers (running on fast graphics processors), collects the results back, and returns them to the client.
The rope across the gorge is one client talking to a broker talking to one worker. We draw three boxes: client, broker, and worker. We draw arrows from box to box showing the request flowing one way, and the response flowing back. It’s just like the many diagrams we saw in earlier chapters.
Be minimalistic. Our goal is not to define a real architecture, but to throw a rope across the gorge to bootstrap ...
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