这样做的后果是与large number组件相关联的概念开销变得可以接受。有争议的是，我们可以建立一个大多数类只暴露的系统
一种单一的公共方法，通过将这些片段总结为疯狂来构建整个系统。在我们这个例子中，给了几件事情。您的应用程序的用户界面具有形成最高服务的一些功能需求。后端系统控制下部。但在这两者之间，一切都是为了抓住。
我们不断的讨论真的是为什么我们在课堂上分组，原则应该是什么？有几件事情是肯定的;门面图案已经死亡和埋葬。任何包含多个不相关功能的服务也倾向于分解。 “不相关的功能”的解释比我以前做的非常严格。
在我们的团队中，有两条盛行的思路：实施依赖关系限制分组;单个类中的任何功能最好是所有注入依赖关系的客户端。我们是一个DDD项目，另一个部分认为域限制分组(CustomerService或更细粒度的CustomerProductService，CustomerOrderService) – 注入依赖关系的标准化使用是不重要的。
所以在松散耦合的DI宇宙中，为什么我们将逻辑分组在类中？
编辑：duffymo指出，这可能正在朝着编程的功能风格发展;这带来了国家的问题。我们有很多代表(小)相关应用状态的“状态”对象。我们将这些注入到任何对此状态有合法需求的服务中。 (我们使用“状态”对象而不是常规域对象的原因是spring会在未指定的时间构造这些对象，我认为这是一个轻松的解决方法或替代解决方案，让Spring管理域对象的实际创建，可能会有更好的解决方案这里)。
所以例如任何需要OrderSystemAccessControlState的服务都可以注入这个，而且这个数据的范围不是消费者所不知道的。一些安全关联状态通常用于很多不同的级别，但是在其间的级别上完全不可见。我真的认为这是从根本上违背功能原则的。我甚至很难从OO角度对这个概念进行调整，但是只要注入状态是精确而强烈的类型，那么用例就是合法的。
高凝聚力
In computer programming,cohesion is a
measure of how strongly-related or
focused the responsibilities of a
single module are. As applied to
object-oriented programming,if the
methods that serve the given class
tend to be similar in many aspects,
then the class is said to have high
cohesion. In a highly-cohesive system,
code readability and the likelihood of
reuse is increased,while complexity
is kept manageable.Cohesion is decreased if:
06000
disadvantages of low cohesion (or “weak cohesion”) are:
06001
当人们对IoC容器疯狂时，失去了一件事情就是失去了内聚力，而且跟踪什么以及如何做某些事情成为一个噩梦，以便在后面找到自己的道路，因为所有的关系都被一堆XML配置所掩盖文件(Spring我正在看你)和不良命名的实现类。
