架构点滴(一):企业应用
语境设定:三层架构——表现层、领域层、数据源层。
叙述:有时,层次组织成 领域层对表现层完全隐藏了数据源层。但更多的时候,是表现层直接对数据存储进行操作。虽然这样做并不纯粹,但是在实践中往往运行良好。表现层可能解释来自用户的命令,通过数据源层将相关数据从数据库中提取出来,然后让领域逻辑层在向用户显示相关数据之前先处理这些相关数据。(《企业应用架构模式》机工,2010,第14页)
我的看法:领域层的职责分散了一些到其他两层——部分领域逻辑分布在了表现层和数据源层以及它们的接口。比如“表现层直接对数据存储进行操作”,操作方法包含了领域逻辑,在实现中领域逻辑被折叠到方法内部了,但其中的领域逻辑在系统抽象中并不能被忽略。故,这些破坏层次分界的做法并不影响我们把系统架构抽象为表现、领域、数据源三个层次,因为系统中的职责仍然是这三种。
我的建议:良好的架构应该保证分散在外的领域逻辑仍然是受到管理的。为此,建议采取的一个基本行动是:保持分散的逻辑块的可追迹性;进而,维护一个与实际系统尽量一致的分层抽象。
--------------------------------------------------------------------------------------------------------------------------------------------------------------
以上为以前写的内容,现在有了新的想法。
--------------------------------------------------------------------------------------------------------------------------------------------------------------
组件式的架构更适合这个场景:对组件要求内聚,组件打破各层的界限,解决“要不要严格分层”的难题。
组件就是一个个可组合、可追迹的逻辑块,它们是架构的原子单位,通过对它们的不同组合,分层变成了可变的,乃至动态的。层次分界不再是圭臬,破坏分界也不会造成不好的影响——可追迹性和受管理性使得一个架构即使没有固定的分层,也是可重用的,因为仍然存在一个基础抽象(base abstraction)。如今接触EJB后,我发现它就是一个好例子——Managed Beans和JNDI。另外,还听说了WebBeans,这样的组件有利于职责在层间的迁移。
同时,演化体系也得到了细粒度的分离。原本的三层架构是分成三个演化方向,现在每个组件就是一个演化方向。这是一个细粒度的Bridge Pattern。