架构点滴（一）：企业应用

语境设定：三层架构——表现层、领域层、数据源层。

叙述：有时，层次组织成 领域层对表现层完全隐藏了数据源层。但更多的时候，是表现层直接对数据存储进行操作。虽然这样做并不纯粹，但是在实践中往往运行良好。表现层可能解释来自用户的命令，通过数据源层将相关数据从数据库中提取出来，然后让领域逻辑层在向用户显示相关数据之前先处理这些相关数据。（《企业应用架构模式》机工，2010，第14页）

 

我的看法：领域层的职责分散了一些到其他两层——部分领域逻辑分布在了表现层和数据源层以及它们的接口。比如“表现层直接对数据存储进行操作”，操作方法包含了领域逻辑，在实现中领域逻辑被折叠到方法内部了，但其中的领域逻辑在系统抽象中并不能被忽略。故，这些破坏层次分界的做法并不影响我们把系统架构抽象为表现、领域、数据源三个层次，因为系统中的职责仍然是这三种。

我的建议：良好的架构应该保证分散在外的领域逻辑仍然是受到管理的。为此，建议采取的一个基本行动是：保持分散的逻辑块的可追迹性；进而，维护一个与实际系统尽量一致的分层抽象。

--------------------------------------------------------------------------------------------------------------------------------------------------------------

以上为以前写的内容，现在有了新的想法。

--------------------------------------------------------------------------------------------------------------------------------------------------------------

组件式的架构更适合这个场景：对组件要求内聚，组件打破各层的界限，解决“要不要严格分层”的难题。

组件就是一个个可组合、可追迹的逻辑块，它们是架构的原子单位，通过对它们的不同组合，分层变成了可变的，乃至动态的。层次分界不再是圭臬，破坏分界也不会造成不好的影响——可追迹性和受管理性使得一个架构即使没有固定的分层，也是可重用的，因为仍然存在一个基础抽象(base abstraction)。如今接触EJB后，我发现它就是一个好例子——Managed Beans和JNDI。另外，还听说了WebBeans，这样的组件有利于职责在层间的迁移。

同时，演化体系也得到了细粒度的分离。原本的三层架构是分成三个演化方向，现在每个组件就是一个演化方向。这是一个细粒度的Bridge Pattern。