Questions tagged «architecture»

我想创建一个系统，处理来自各种程序的警报消息，并可以通过电子邮件将这些警报处理给顺风顺水的消费者。所有这些都将包含在一个内部网络中。 我想我希望基本架构看起来像这样： 我目前主要关心的是“消息处理程序”位，这就是我的“ API排序”。我希望该系统的所有组件将数据发送到API，该API处理所有对数据库的写入。我认为这种方法比较容易，因为它简化了安全性，并允许我将许多更复杂的数据库查询包含在一个程序中。 令人担心的是，我希望这与语言无关，这意味着任何代码都应能够将消息发送到我的处理程序，由它来解释它们。我希望通过JSON平面文件-或通过对该程序的REST调用（为下游应用程序提供灵活性）来做到这一点。 我的问题是 我应该烦恼消息处理程序吗？或者它会增加简单性，使其仅允许直接数据库访问下游应用程序以及其他两个组件（管理控制台和警报管理器）？ 这样，他们就可以插入想要的任何警报-只要将INSERT插入数据库表中即可。 我不是专业的软件设计师，所以请原谅-我只想在业余时间做一个项目。

10 design  design-patterns  architecture  api  api-design 

据说无服务器体系结构的主要优点是，此类程序不需要专用服务器即可连续运行。然后在请求上被调用，并在退出函数时停止。 这意味着无服务器程序必须快速启动才能响应。然后，它如何处理耗时的操作，例如数据库连接？它是否每次都连接到数据库，还是单独管理数据库连接以像服务器应用程序中那样进行功能调用？

10 architecture  server  backend 

我是一名业余开发人员，到目前为止，我的所有程序都很简单，可以在代码中进行记录。在阅读代码时，很清楚我在做什么和这样做（我的标准测试是6个月后查看代码，并在初读时了解所有内容-我的内存跨度很短）。 我现在面对的是一个程序，该程序超出了我记住这些程序之间各种交互的能力。 代码本身 数据库中的索引 各种模块之间的交互（“工作人员”核心代码和“库”模块） 我当前的文档是一个白板，其中有各种各样的框和箭头，它们指向代码，数据库索引，正在执行的操作，状态更改等。仅供参考，一团糟： 我的问题是，对于更复杂的产品的文档记录，是否存在一套标准的或最佳实践的最佳实践集（命名为这是一组以特定名称分组的实践）。 我应该寻找什么关键字（对“文档软件体系结构标准”的一般尝试以及类似的变体，通常会导致用于工作流或建筑体系结构CAD系统的软件）。 我还希望对高级描述没有通用的最佳实践，并且每个人都可以建立自己的哲学。

10 architecture  documentation 

我有许多构成Web应用程序的Web服务。客户端可以通过REST API调用访问这些服务。 这些服务应该能够彼此直接对话吗？如果是这样，这是否会使他们成为夫妇，这违背了微服务的概念？ 客户端是否应该一个接一个地直接调用它们以获取在客户端上加载网页所需的数据？ 还是我应该在服务之上设置另一层来处理来自客户端的请求，获取该请求的数据，然后将其发送回客户端？

10 architecture  rest  microservices 

新计算机体系结构的提供者经常尝试引入新的编程模型，例如，最近用于GPGPU的CUDA / OpenCL，并取代C / POSIX作为平台并行性的控制接口。（Poss＆Koening，AM3：迈向面向多核的硬件Unix加速器，2015年） 为什么架构设计师尝试设计新的编程模型来代替C / POSIX进行并行计算？C / POSIX是不是非常适合多处理器，还是C / POSIX的原始作者在C / POSIX设计时就没有考虑并行计算的需求？还是程序员需要比C / POSIX所提供的功能更多的功能，从而诉诸于CUDA / OpenCL等新设计？

10 architecture  multithreading  parallelism  posix 

我正在阅读“ 在MVC中模型应该处理验证吗？ ”，因为我很好奇验证逻辑在MVC网站中的位置。最高答案中的一行如下：“控制器应处理验证，模型应处理验证”。 我很喜欢，但是让我感到奇怪的是，为什么由于以下几个原因我们不会在View中进行数据验证： 视图通常具有强大的验证支持（JS库，HTML5标签） 视图可以在本地验证，从而减少网络IO 用户界面已经考虑了数据类型（日期的日历，数字的微调框），使其距验证仅一步之遥 在多个地方进行验证与MVC隔离职责的概念背道而驰，因此“在两个地方都做”似乎不合适。仅在控制器中执行数据验证是真正的主导方法吗？

10 architecture  mvc 

我认为可以肯定地说，大多数Web应用程序都基于请求/响应范例。PHP从未对这些对象进行正式的抽象。一个小组正在尝试改变这一点：https : //github.com/php-fig/fig-standards/blob/master/proposed/http-message.md 但是，他们在不变性问题上有些偏颇。一方面，请求/响应对象通常在其生命周期内几乎不需要更改。另一方面，响应对象尤其经常需要添加HTTP标头。 此外，不变性从未真正在PHP领域流行。 人们在使用不可变的请求/响应对象时会看到哪些优势？ 假设您要返回一个json对象。 $response = new JsonResponse($item); 漂亮又简单。但是事实证明，该请求是跨域资源共享（CORS）请求。生成响应的代码无关紧要，但是下游的某个过程将添加必要的Access-Control标头。保留原始响应并使用其他标题创建新响应有什么好处？还是严格来说是编程风格的问题。 请求对象更加有趣。它从相同的地方开始： $request = new Request('incoming request information including uri and headers'); 初始信息不需要更改。但是，随着请求的传递，通常需要添加其他处理信息。例如，您可能有一个URL匹配器，该匹配器决定应为给定请求执行什么操作。 $request->setAttribute('action',function() {}); 实际执行操作是下游流程的责任。您可能有一个可变的RequestAttributesCollection，它包装了不可变的请求，但在实践中往往有些尴尬。除了属性集合之外，您还可能有一个不变的请求。异常也往往很尴尬。处理此类要求有经验吗？

10 design  php  web-development  architecture 

主要问题 眼看着良好的支持最先进的编程平台有包管理（想想gem，npm，pip，等），它是有意义的设计应用程序或系统由内部开发的软件包，从而促进并创建一个松散耦合的架构？ 例 这样的一个示例是创建用于数据库访问以及用于身份验证和系统其他组件的软件包。当然，这些也使用外部程序包。然后，您的系统导入并使用这些软件包-而不是将其代码包含在自己的代码库中。 注意事项 对我来说，这似乎可以促进代码去耦并提高可维护性，几乎是一种基于Web的桌面应用程序方式（更新几乎是自动应用的，单一功能的单一代码库，等等）。 这看起来像是一个合理而理智的设计概念吗？如今，这实际上已用作构建应用程序的标准方法吗？

10 design  design-patterns  architecture  packages  coupling 

如果两个Scrum团队使用相同的软件组件，谁负责提供该组件的清晰架构构想并随着代码库的发展维护/开发该构想？在Scrum中，您应该拥有集体代码所有权，那么如何确保团队A的开发不会干扰团队B的开发呢？

10 architecture  scrum  code-quality  configuration-management 

我正在使用允许管理员定义包含字段的表单的系统。然后，使用定义的表格将数据输入系统。有时，表单是由用户通过GUI填写的，有时，表单是根据另一个系统报告的值来填写的。 对于每个字段，管理员可以定义一个验证规则，以限制该字段的允许值。验证规则可以是“在字段中输入的值必须为True或False”到“在字段中输入的值必须存在于数据库表B的A列中”的任何内容。管理员可以随时更改字段的验证规则。 在这种情况下，您认为最适合验证每个字段正确填写的位置是什么？我目前有两种主要方法： 选项1：在域模型中验证 每个字段对象将包含管理员指定的验证规则。Field对象还将引用IValidator。尝试设置字段的值时，字段会将给定的值和验证规则传递给IValidator。如果给定的值无效，则将在另一个系统的GUI /接口中引发ValidationException并进行适当处理。 优点： 强大的保护功能，防止字段被意外分配违反验证规则的值 缺点： 数据访问层需要能够绕过验证并构造违反当前验证规则的字段。尽管管理员更改了字段的验证规则，但我们仍然需要能够基于旧数据构造Field对象，例如，当渲染多年前填充的表单时。每当我们存储字段时，都可以通过存储当前的验证规则来解决此问题。 在这种设计中，Field模型通过IValidator间接链接到数据访问层/存储库。服务/存储库的领域模型的注入似乎被普遍令人难以接受的。 选项2：在服务中验证 尝试确保所有尝试设置字段值的尝试都通过可确保验证规则成立的服务。如果违反了验证规则，则抛出ValidationException。 当然，当创建以前一直保存在数据库中的字段对象时，数据访问层将不会使用服务。 优点： 不违反“不要将服务/存储库注入您的域模型”的思想。 保留字段时，无需保留当前的验证规则。该服务可以简单地查询该字段的当前验证规则；查看历史记录数据时，字段的值不会更改。 缺点： 不能保证应该使用服务设置字段值的所有逻辑实际上都这样做。我认为这是一个主要缺点。似乎要做的就是有人写“ thisField.setValue（thatField.getValue（））”，并且可能会违反thisField的验证规则，而没有人明智。当数据访问层将要保留字段时，可以通过确保字段的值与验证规则匹配来缓解这种情况。 我目前更喜欢选项＃1，而不是选项＃2，主要是因为我将其视为业务逻辑，并认为选项2带来了将不良数据引入系统的更大风险。您更喜欢哪个选项，或者是否有比上述两个选项更适合这种情况的设计？ 编辑（验证的复杂性） 目前出现的验证案例相对简单。字段值必须是例如数字，日期，带时间的日期，或者是数据库列中的现有值。但是，我怀疑复杂性会随着时间逐渐增加。例如，验证解决方案的构建必须考虑国际化-诸如Date之类的内容可能会以特定于语言环境的语法输入。 我现在决定继续使用选项＃1，尝试注意不要为域模型分配太多职责。那些面临类似情况的人可能还想查看相关问题分层体系结构中的验证和授权以及数据输入验证-在哪里？多少？。

10 design-patterns  architecture  domain-driven-design  validation 

我不能为我的纸牌游戏提出一个好的架构。我需要帮助来了解游戏通常是如何设计的。 首先，我将描述游戏规则。 游戏规则 设定 有四名球员，每两名球员组成一个团队。 每位玩家可获得12张随机洗牌 桌子上有4张盲卡（河牌） 玩家订购是这样的 下注 每个玩家都可以在100到160之间传递或选择一个大于当前下注的数字 博彩从第一位玩家开始，直到圈子通过为止 一旦玩家通过，就不能再下注 赢得下注回合的球队至少应获得等于其下注的积分才能赢得比赛 输掉了本轮比赛的团队不应允许其团队达到目标 如果赢得比赛的团队获得所有分，则另一支球队将获得等于其赌注的负分 如果输掉比赛的队伍获得了所有积分，另一支队伍将获得双倍负积分 游戏流程和收集点 赢得下注的玩家（国王）在桌上获得了剩余的四张牌。 然后，她/他甚至可以不用玩就将一组四张卡保存在他们的团队卡库中。 国王将挑选一套西装作为尺码西装，并让其他人知道 King通过将他/她的手牌放在桌子上来开始游戏。每个其他玩家应按此顺序玩 如果他们手中持有与该张牌相同的花色，则必须打出其中一张 如果他们没有，他们可以玩其他西装 在所有其他玩家玩过手之后，该回合的赢家将是： 如果所有卡都相同，则拥有最高卡的人 拥有最高“统治者”卡的人 一轮获胜者将收集卡并将其放入银行 赢得前一轮的玩家将开始下一轮 这将一直持续到每个人的手都空了 计数点 每个回合赢5分。这意味着每4张卡至少有5分。 拥有Ace，银行中的10点或5点各加5点 我的设计 班级 class Card { string suit; string rank } class Deck { List cards = []; List …

10 architecture 

在对大型系统进行更改时，我经常会遇到一个问题，即某些功能需要从另一部分中获取一些数据，但是它们位于深度和分支调用树的不同部分中，可能流经事件侦听器，延迟调用，等。这样，简单的更改就会迅速膨胀。 Yossi Kreinin的博客文章（http://www.yosefk.com/blog/i-want-a-struct-linker.html）的相关引用： 您有很多传递的数据结构。很快，关于该结构的最有价值的事情不是它保留的数据，而是通过一些繁琐的控制流程一直可用的事实。 全局变量是让代码“呼喊”到遥远的代码的一种经典方法，但众所周知它们存在问题。动态范围变量是一种更受限制的方法，但它们也存在问题。 是否有旨在解决此问题的编程语言研究？我们是否可以更轻松地将意外的数据流添加到大型代码库中，同时仍具有静态检查，简便的单元测试和其他优点？

10 programming-languages  architecture 

我在寻找以下架构问题的适当解决方案时遇到了一些麻烦。 在我们的设置（如下所示）中，我们有2个数据源，其中数据源A是Foo类型项目的主要来源。存在辅助数据源，可用于检索Foo上的其他信息。但是，此信息并不总是存在。 此外，数据源A可用于检索Bar类型的项目。但是，每个Bar都指一个Foo。这里的困难在于每个Bar应该引用一个Foo，如果有的话，它还包含由数据源B扩充的信息。 我的问题是：如何消除SubsystemA.1与DataSourceB之间的紧密耦合？

10 architecture 

我目前正在两种可行的软件设计/解决方案之间进行选择。解决方案1易于实现，但会以专有格式锁定某些数据，以后将很难更改。解决方案2难以实现，但以后将更容易更改。 我应该选择YAGNI还是应该将退出成本纳入决策？还是换个角度问，退出成本是TCO的一部分吗？ 我正在考虑再回头问客户，他是否认为退出成本是相关的，但我想知道社区首先想到的是什么。 PS退出成本是否正确？

10 design  architecture  terminology  decisions 

在可以忽略性能影响（最大每秒10-20个事件）的应用程序框架中， 什么是更可维护且更灵活的方法，可以用作模块之间进行通信的首选介质-事件还是期货/承诺/单子？ 人们常说，事件（发布/订阅，中介）允许松散耦合，因此-应用程序更易于维护...我的经验否认这一点：一旦您拥有20多个事件，调试就会变得很困难，重构也会变得更加困难-因为很难看到：谁，何时何地使用什么。 承诺（我用Java语言编写）比事件要丑陋得多。但是：您可以清楚地看到函数调用之间的连接，因此应用程序逻辑变得更加简单明了。我怕什么 但是，Promises会带来更多的困难吗？ ps：答案不一定基于JS，非常欢迎其他功能语言的经验。

10 architecture  maintainability  async  event-programming  monad