Question

I’ve just watched Uncle Bob’s presentation on Architecture software :

http://www.cleancoders.com/codecast/clean-code-episode-7/show

He talks about ECB pattern (Entities – Controllers – Boundaries)

He insists on the fact that all softwares must be primary though as a whole of Use Cases.

Indeed, he repeats a lot of times that decisions concerning tools, frameworks etc… must be deferred.

I have been intrigued by the term “Boundaries”, so I’ve found this explanation :

http://process.osellus.com/sites/wiki/OpenUP%20DSDM/Wiki%20Pages/Guidance%20-%20Entity-Control-Boundary%20Pattern.aspx

Here we see that boundaries are relevant to each delivery mechanism like a form for web mechanism (MarketingCampaignForm) etc…

So my question is :

Do boudaries have to know about type of delivery mechanism that will be used and so contradictory with Uncle Bob’s point of view?

Or they must be simple POJO’s representing simple datastructure that will be shared between inner system and delivery mechanism; and containing input from user and output from controllers in inner system ?

Answer 1

A bit stretched maybe (purists will hate me) but you can think of a boundary as conceptually similar to the view in MVC, although it’s a more general concept: if your system exposes a REST API, for instance, this cannot really be called a view (nor you’re implementing MVC, fwiw) but it’s, more generally, an interface of your system towards the external world.

In other words, a boundary is the part of your system that interacts with use case actors, that is humans or systems outside of your system.

From Eclipse EPF:

A boundary element lies on the periphery of a system or subsystem, but
within it. For any scenario being considered either across the whole
system or within some subsystem, some boundary elements will be “front
end” elements that accept input from outside of the area under design,
and other elements will be “back end,” managing communication to
supporting elements outside of the system or subsystem.