Patterns for non-layered applications

Question

In Patterns of Enterprise Application Architecture, Martin Fowler writes:

This book is thus about how you decompose an enterprise application into layers and how those layers work together. Most nontrivial enterprise applications use a layered architecture of some form, but in some situations other approaches, such as pipes and filters, are valuable. I don't go into those situations, focussing instead on the context of a layered architecture because it's the most widely useful.

What patterns exist for building non-layered applications/parts of an application? Take a statistical modelling engine for a financial institution. There might be a layer for data access, but I expect that most of the code would be in a single layer. Would you still expect to see Gang of Four patterns in such a layer? How about a domain model? Would you use OO at all, or would it be purely functional?

The quote mentions pipes and filters as alternate models to layers. I can easily imagine a such an engine using pipes as a way to break down the data processing. What other patterns exist? Are there common patterns for areas like task scheduling, results aggregation, or work distribution? What are some alternatives to MapReduce?

Answer 1

I think what Fowler means is that in a layered application the focus is on organizing "vertical" de-coupled communications between layers.

Another architecture is SOA (Services Oriented), where the focus it on organizing "horizontal" de-coupled communications between components. (Within a component the implementation may use either model). This is nothing new. Other instances of this horizontal pattern are COM/ COM+, CORBA, workflows, and now "messaging" or ESB architectures.