我刚刚开始研究如何编写好的软件架构 系统，我正在学习如何将高级组件分成层。 在这种情况下，我正在尝试使用Tiers，以便将每个图层建模为黑色 框。
我的架构中有4层：演示文稿，应用服务， 业务逻辑和域/持久性。就我的问题而言， 我们真的只需要专注于演示和应用服务。
应用程序服务层将包含允许跟踪的服务 特定事件。演示文稿应该有几个观点 随着事件的跟踪模型的变化动态更新。本质上， 似乎我需要一种单向变换传播机制。
由于我试图将这些图层建模为层，我想限制通信 在每个层的Facade对象之间，并在必要时允许层 从一个Tier下面聚合一个对象，虽然只有接口知道。
我用Java编写这个应用程序，所以显而易见的是使用它 可观察/观察员。但是，我不喜欢那种更新方法 Observer接口强制您转换对象参数。我想解决 这是通过为这个机制定义我自己的接口和类。问题， 那么，应用逻辑是否依赖于Presentation的界面 Tier，这个架构肯定是禁忌。这是我应该尝试的标志吗？ 使用MVC进行最前端建模并对模型进行分层？或者是一个更好的主意 使用Application Services Layer中已知的接口为每个视图建模。 它似乎是一个糟糕的地方，我被困住了。此外，我正在使用View-Handler设计模式来处理多个视图。
答案 0 :(得分：0)
Observer / Observable通常不是最好的方法，特别是在Java中，你必须从Observable派生，从而浪费你的单一继承。正如你所讨论的那样，它也会导致耦合，当它跨越层时会很糟糕。
我更倾向于研究一个纯粹的事件模型，这些服务提供了一种方法来注册EventListeners并在发生更改时触发PropertyChangeEvent。
然后，服务层可以通知其他服务，或者通知表示层 - 它不知道也不关心，只有表示通过注册为监听器而与服务耦合。
答案 1 :(得分：0)
在我看来，您的问题与发布/订阅相关，而不是如何让图层进行通信。
简短回答：
使用MVC / MVP。查看关于它们的博客文章，下载源代码，并记住：如果你拥有的只是一把锤子，那么一切看起来都像钉子一样。意思是不应用模式，因为你有它们，因为你需要它们来应用它们。
答案很长：
如果您使用的是Java，我建议使用Head First Design Patterns，这将使您了解模式中的思维方式。在你了解设计模式后，我认为你现在正在前进，你可以看看Patterns of Enterprise Application Architecture。随意跳过Head First，但如果你进入建筑领域，我强烈推荐这本书。
一旦你消化了福勒的书，或者至少对N层企业架构有了基本的了解，你就应该顺利完成。