But Uncle Bob, what about the Input Boundary

746 views
Skip to first unread message

Ramon Chiara

unread,
Jun 27, 2014, 9:07:11 AM6/27/14
to clean-code...@googlegroups.com
Hi,

I'm trying really hard to figure it out how to implement (code for God's sake) a lot of details in a "True" Clean Architecture as depicted by Uncle Bob (http://www.verschoorweb.nl/wp-content/uploads/2013/03/tumblr_m7wjx4QuLX1qz82meo1_1280.png).

But, for now, I have to ask about the necessity of the Input Boundary interface which is implemented by a Use Case.
Do we really need do decouple it from the Controller?
By what I see, the Controller is specific to the Use Case.
If I'm testing, the test class is our Controller and it is specific to the Use Case.
If it's a Servlet, it will be specific to the Use Case.
So, why do I need to create a lot of infrastructure (Interface and, by what I've read here, a UseCaseFactory)?

In time, couldn't we start a common project to discuss all this?
One that starts with a test, testing a use case, implementing a use case, with validations, business rules, application rules, etc.?
Then we could go to create a specific delivery mechanism to see it working.
Then another delivery mechanism and so on.

What I see is a lot of different projects trying to implement the Clean Architecture, each one with it's own ideas.
What Id like to see is: if I do this way, would Uncle Bob give a "Clean Architecture Badge"? ;-)

Best regards!!!


unclebob

unread,
Jun 27, 2014, 10:04:45 PM6/27/14
to clean-code...@googlegroups.com
Ramon, there's no reason that the controller can't know about the use case.  The important thing is that the use case not know about the controller.  That means you don't want any of the data elements passed to the use case to have controller-like dependencies.  

The so-called "Clean Architecture" breaks those controller like dependencies by creating a plain-old data structure from the HttpRequest and passing that data structure to the use case.  In the simplest case that data structure doesn't need to be a class at all, it can just be a list of arguments to a method in the use-case.

The use-case has an implementation.  We probably don't wan the controller coupled to the implementation of the use case.  So, in Java, and C# we put the use case behind an interface. In Ruby or Python that interface isn't necessary and the use-case method can simply be invoked from the controller directly.  

Who creates the use-case object?  Whoever does that knows the name of the concrete use-case class, and therefore has a dependency on the use-case implementation.  To break that, we use a factory, or some other form of dependency injection.

Ramon Chiara

unread,
Jun 28, 2014, 1:26:18 PM6/28/14
to clean-code...@googlegroups.com
Uncle Bob,

Thanks a lot for your answer!
For what I understood I shouldn't be worrying so much about some details since I keep dependencies pointing towards the center of "the onion"! :-)

Best regards!
Reply all
Reply to author
Forward
0 new messages