我刚看过Bob叔叔关于架构软件的演讲：
http://www.cleancoders.com/codecast/clean-code-episode-7/show
他谈到了ECB模式（实体 - 控制器 - 边界）
他坚持认为所有软件必须是主要的，尽管整个用例。
实际上，他重复了很多次关于工具，框架等的决定......必须推迟。
我对“边界”一词很感兴趣，所以我找到了这个解释：
在这里，我们看到边界与每个交付机制相关，如Web机制的形式（MarketingCampaignForm）等......
所以我的问题是：
boudaries必须知道将使用的交付机制的类型，并与Bob叔叔的观点相矛盾吗？
或者它们必须是简单的POJO，表示将在内部系统和传递机制之间共享的简单数据结构;并包含来自用户的输入和内部系统中控制器的输出？
答案 0 :(得分：4)
有点拉伸（纯粹主义者会讨厌我），但你可以认为边界在概念上类似于MVC中的 view ，尽管它是一个更通用的概念：例如，如果您的系统公开了一个REST API，那么它实际上不能被称为视图（您也不是实现MVC，fwiw），但更常见的是，它是您的系统与外部世界的接口。
换句话说，边界是系统中与用例参与者交互的部分，即人类或系统 系统。
来自Eclipse EPF：
边界元素位于系统或子系统的外围，但 在其中。对于在整个过程中被考虑的任何场景 系统或某些子系统内，一些边界元素将是“前面的 结束“接受来自设计区域外的输入的元素， 和其他元素将“后端”，管理沟通 支持系统或子系统的外部元素。