非分层应用程序的模式
Martin Fowler 在《企业应用程序架构模式》中写道：
这本书是关于你如何 分解企业应用程序 分层以及这些层如何工作 一起。 最不平凡的企业 应用程序使用分层 某种形式的建筑，但在某些方面 其他方法的情况，例如 管道和过滤器都很有价值。 我 不要陷入这些情况， 相反，将重点放在a的上下文上 分层架构，因为它是 最广泛有用。
构建非分层应用程序/应用程序的一部分存在哪些模式？ 以金融机构的统计建模引擎为例。 可能有一个用于数据访问的层，但我希望大部分代码都在一个层中。 你还会期望在这样的层中看到四人帮的图案吗？ 领域模型怎么样？ 您会使用面向对象，还是纯粹使用函数式？
引用中提到管道和过滤器是图层的替代模型。 我可以很容易地想象这样一个引擎使用管道作为分解数据处理的方式。 还存在哪些其他模式？ 任务调度、结果聚合或工作分配等领域是否存在通用模式？ MapReduce 有哪些替代方案？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为福勒的意思是，在分层应用程序中，重点是组织层之间的“垂直”解耦通信。
另一种架构是 SOA（面向服务），其重点是组织组件之间的“水平”解耦通信。 （在组件内，实现可以使用任一模型）。 这不是什么新鲜事。 这种水平模式的其他实例包括 COM/ COM+、CORBA、工作流以及现在的“消息传递”或 ESB 架构。
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.