I can see you are a big fan of system design improvements that’s why came for more :). That’s very good. Indeed, I want to show you what can we do to improve our SRC cards and take even more out of them.
The Original Tool To Rule All System Designs
As you remember from SRC card post our cards have System, Responsibilities and Collaborators sections. In C section we list all the systems that we communicate with to do our job, or systems that we know of, that use us to do their job. Up until now it was all mumbled together.
The Better
So how can we improve? We know that for sure Notification Service does not call us right? Let’s add another level of distinction in collaborators section, lets split them into Upstream and Downstream collaborators.
Upstream collaborator
An upstream collaborator is a service, component or system that will call us. He is responsible for control flow, he initiates the communication, he knows when and what he needs. We are just sitting there waiting to be invoked.
Downstream collaborator
A downstream collaborator on the other hand is the one that we need to call to do our job. We have control, and we decide whom to call when and for what.
As you can see there is a mirror relationship between upstream and downstream, so if system AuctionX has a downstream collaborator Shipping and Handling then Shipping and Handling has an upstream collaborator in the form of AuctionX.
Another Level Of Details In Our System Design
So let’s try to rewrite our SRC cards with this Upstream/Downstream distinction.
Whoa, man! You messed it up, you’ve copied both of those systems in both places!
Exactly. Because in this particular example AuctionX does invoke S&H to post a package, so it’s in Upstream collaborators part, but S&H also notifies AuctionX that the package was sent. And again Notification service will get a trigger to notify user, but It will need more details about package.
There is another possibility of implementation in which all the necessary details are passed directly from AuctionX to S&H and from S&H to Notification Service, and that AuctionX does not care at all about shipping process. In which case our card would look like:
Describing it like this, actually adds a very nice detail. What is it ? Here we KNOW that S&H does not need to have access to AuctionX (which can be in Internet, while S&H is in intranet). Then if somebody says that S&H can just ask AuctionX for some more details, or update status, we can immediately see that the’ve never talked with each other in that direction and there is probably some more work to be done other than code changes itself.
Yes, we add some implementation considerations already. Is it good or is it bad? For me, you can always generalize if you have details, but not the other way around. So I would add them and if someone wants to ignore them, fine. The underlying message of whom do we talk with (both ways) is still present.
Summary
We can add additional levels of details, to aid better understanding of our system design. This tool needs to serve us! We should add an Upstream/Downstream collaborator’s distinction, and add communication pattern details as well, who actually calls whom, not just a logical connection, but actual service invocation directions.
Hope you liked it, let me know if any questions 🙂
Happy designing everyone!