In Uncle Bob’s Clean Architecture, he provides the following diagram:
This diagram is used for discussing the Open-Closed Principle (OCP). I understand that the interface Financial Report (FR) Requester is there to hide the internals of the Interactor. However, I am struggling to understand why there are not arrows pointing from the FR Requester to the request and response data structures.
I imagine the code for it would look something like this:
class FRGenerator implements FRRequester {
FRResponse handleRequest(FRRequest request) {
// handles request
}
}
interface FRRequester {
FRResponse handleRequest(FRRequest request);
}
In my example we can see the interface directly relies on the request and response.
Is my understanding correct? If so, then why don’t we draw these dependencies in the diagram?
0
Is my understanding correct?
Your understanding is correct, but I’m going to push back on the assertion that the diagram must invariably have listed this. The primary goal of a diagram is to communicate a concept to other people, using visualizations.
This comes with the cost of needing to consider what is relevant information, and what is clutter. Clutter detracts from your message by making the diagram more complex than it needs to be and adding distractions.
Sure, the particular thing you’re pointing out would’ve been solved by two relatively unintrusive arrows that don’t cross anything.
However, things aren’t always as easy to visualize as they were here. And even then, while this version is a more accurate representation of the dependency graph that will be in the code, it makes it harder to parse the flow of the diagram.
By omitting those arrows, it’s visually easier to parse that the request/interface/response forms a separating wall between the controller and generator (represented by blue vs red in the below image)
If I were the author, after reading your question I would be inclined to add a footnote to point out the absence of those arrows; but that’s optional. Uncle Bob’s documentation has had a lot of consideration for editing what is sufficiently relevant and what isn’t, so I can’t judge the editing process of this book (I’ve never written anything near as popular as that).
I also just want to take the time to point out that people naturally omit details from diagrams, just as much as readers naturally don’t even notice those omissions most of the time.
For example, you’ve not asked where the data structures are that are being used in the Financial Report Presenter. You’ve also not asked about why there’s no arrow between the Financial Data Gateway and the Financial Entities.
These should be equally relevant to bring up, but they weren’t part of your question. And the thing is, I don’t think they should’ve been added. The added complexity far outweighs the value from the pedantical correctness, meaning it overall detracts from readability, which is bad for a diagram.
This is just an educated guess, but I suspect that the only reason the Financial Report Request/Response objects are listed so explicitly (more so than the others) is because of there being two consumers of the response data structure:
Needing to highlight this dual dependency forces the hand of the diagram author to explicitly add the response object (to highlight the dual dependency) and the request object (to indicate a lack of dual dependency).
But the author likely felt (like I do) that this shouldn’t lead to all data structures needing to be listed explicitly everywhere in the diagram, because that would be overkill with no meaningfully added value.
2