title: ECB pattern - what is really a boundary?
body: <p>I've just watched Uncle Bob's presentation on Architecture software :</p>
  
  <p><a href="http://www.cleancoders.com/codecast/clean-code-episode-7/show" rel="nofollow">http://www.cleancoders.com/codecast/clean-code-episode-7/show</a></p>
  
  <p>He talks about ECB pattern (Entities - Controllers - Boundaries)</p>
  
  <p>He insists on the fact that all softwares must be primary though as a whole of Use Cases.</p>
  
  <p>Indeed, he repeats a lot of times that decisions concerning tools, frameworks etc... must be deferred.</p>
  
  <p>I have been intrigued by the term "Boundaries", so I've found this explanation :</p>
  
  <p><a href="http://process.osellus.com/sites/wiki/OpenUP%20DSDM/Wiki%20Pages/Guidance%20-%20Entity-Control-Boundary%20Pattern.aspx" rel="nofollow">http://process.osellus.com/sites/wiki/OpenUP%20DSDM/Wiki%20Pages/Guidance%20-%20Entity-Control-Boundary%20Pattern.aspx</a>  </p>
  
  <p>Here we see that boundaries are relevant to each delivery mechanism like a form for web mechanism (MarketingCampaignForm) etc... </p>
  
  <p>So my question is :</p>
  
  <p>Do boudaries have to know about type of delivery mechanism that will be used and so contradictory with Uncle Bob's point of view? </p>
  
  <p>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 ?  </p>