Questions tagged «architectural-patterns»

我正在阅读 JDOM的网站。 为什么用具体的类而不是接口来定义JDOM API？ Jason Hunter总结了针对JDOM的基于接口的API的论点： 使用接口，所有东西都变成了工厂，必须将元素“导入”到新文档中，而不是仅仅添加元素，不能保证诸如长期序列化之类的功能，因此清单还在继续。 我们实际上是从接口开始的。在对某些同伴的发行前审查中，我们收到了反馈，应该尝试具体的课程。我们做到了，并且设计对此要好得多。 我是初学者。到目前为止，我所听到的所有建议都建议不要将设计与具体类一起使用。 可能在某些地方使用具体的类是适当的。是否存在在设计中使用具体类的常见类问题？

10 java  design  object-oriented  architectural-patterns 

JWT规范仅描述了有效负载及其发送方式，但未启用身份验证协议，从而允许了灵活性，但非常不幸的是，灵活性可能导致反模式和设计错误。 我正在寻找一些经过深思熟虑且经过测试的JWT身份验证企业模式，可以使用或改编它，但未能找到完整的东西。 我在想的是： 当未满足任何授权标头或JWT令牌无效或已过期时，发送HTTP 401 为了进行身份验证，请使用/ login REST通道，将用户名和密码作为JSON对象发送 为了使令牌保持活动状态，请使用/ keepalive REST通道，每N（5）分钟调用一次，接收新的JWT令牌，并在每次调用后替换现有的令牌（令牌在M（15）分钟后过期） 但是，令我困扰的是该/ keepalive频道的必要性。另一方面，它迫使我防止身份验证过期，即使用户不在（该决定，如果我们希望仍然不执行keepalive的决定），当然，这是对协议的额外调用和额外复杂性。有趣的是，服务器会自动延长令牌。在基于会话的环境中，它是通过重置时间戳来实现的，但是，在这里，服务器将不得不发送新令牌，可能不是每次都发送一次，但是一旦令牌在R（例如10）分钟内到期，就必须发送新令牌。但是将其放在响应主体中将意味着修改JSON响应协议（因此，该解决方案具有侵入性且不透明），并且将客户端可以处理的额外HTTP标头不一定不一定是一个好模式。一世' 有没有可以解决我的问题的现成企业模式？我的协议草案是否可靠？与从头开始设计相比，我更喜欢使用现成的东西。

9 rest  authentication  architectural-patterns 

我正在阅读事件源，不能停止问自己，这是否仅在非常罕见的情况下才有意义，在这种情况下，写操作很少或需要进行军事级审核。 具有非凡用途的非例外系统每天可能会产生成百上千的写入，相当于每年运行一百万或2次写入（因此发生事件）。与从传统存储中直接读取的内容相比，合并数百万个对象（事件）只是为了获得当前状态，这听起来很荒谬。但是，事件源位于某些性能最高的系统（例如LMAX）的背后。 那么，我想念什么？从事件流恢复状态是否通常已经完成？还是这种想法很少需要这样做，而是完全使用其他存储来进行常规操作（即使用CQRS的查询存储），并且仅在特殊情况下（例如复制，审核等）从事件中恢复？

9 design-patterns  architecture  event-programming  architectural-patterns  event-sourcing 

管道和过滤器的架构模式定义为一系列处理元素，其排列方式是使每个元素的输出为next的输入。每个示例似乎都考虑通过某种共享缓冲区执行的进程间或线程间连接。 在我看来，Haskell函数组合正在执行相同的任务。我们能否说这只是此模式的一个实例，即使它只是关于函数排序，并且没有显式缓冲区用作管道？如果是，对于非惰性语言，我们可以说同样的话吗？

9 design  functional-programming  haskell  architectural-patterns