Questions tagged «architecture»

在任何涉及具有多个开发人员的分布式系统的软件开发项目中，拥有逻辑和物理体系结构图是最佳实践，但是以我的经验，这些图总是在项目开始时就得到很好的维护，但是在项目发布时不会得到更新维护阶段就开始了。 对于具有很多分布式过程的复杂项目，由于没有人知道所有的知识，因此即使在最初发布之前，这些图也往往会很快变得过时或不准确。 在这种背景下，我想向社区提出以下问题： 拥有准确且最新的逻辑和物理架构图有多重要？ 是否有任何工具和流程可以帮助他们保持最新状态？ 谁应该负责使它们保持最新状态？系统管理员，开发人员和质量检查团队如何贡献力量？

12 design  architecture  testing 

现在的情况 我们正在微服务架构中实现（现在正在维护）在线购物Web应用程序。 要求之一是，企业必须能够对客户添加到购物车中的商品应用规则，以自定义其体验和最终订单。很显然，必须建立业务规则引擎，并且为此我们实现了一个特定的“微服务”（如果仍然可以这样）。 在过去的一年中，此规则引擎变得越来越复杂，需要越来越多的数据（例如购物车的内容以及用户信息，他的角色，他的现有服务，一些账单信息等）才能计算这些规则。 目前，我们的shopping-cart微服务正在从其他微服务收集所有这些数据。即使部分资料已由所使用shopping-cart，大部分时间主要还是用来提供规则引擎。 新要求 现在，需要其他应用程序/微服务来重用规则引擎以实现类似的需求。因此，在当前情况下，他们将必须传输相同类型的数据，调用相同的微服务并构建（几乎）相同的资源才能调用规则引擎。 照原样继续，我们将面临几个问题： 每个人（称为规则引擎）都必须重新实现对数据的获取，即使他们自己不需要数据也是如此。 对规则引擎的请求很复杂； 继续朝这个方向发展，我们将不得不在整个网络上传输许多请求的数据（想想μsA调用μsB调用规则引擎，但是A已经有了规则引擎需要的一些数据）； shopping-cart 由于所有数据的获取而变得巨大； 我可能会忘记很多…… 我们怎样做才能避免这些麻烦？ 理想情况下，我们将避免为规则引擎增加更多的复杂性。我们还必须确保它不会成为瓶颈-例如，某些数据的获取速度相当慢（10 s甚至更多），因此我们实施了预提取，shopping-cart以便在调用规则之前数据更有可能存在引擎，并保持可接受的用户体验。 一些想法 让规则引擎获取所需的数据。这将增加它的复杂性，违反了单一责任原则（甚至更多……）； 在规则引擎获取数据之前实施代理μs； 实施规则引擎调用的“数据获取程序”μs，以一次获取其所需的所有数据（复合查询）。

12 design  architecture  enterprise-architecture  microservices  business-rules 

微服务是否应该负责处理自己的授权，或者您认为最好有一个单独的授权服务，该服务在微服务的全部或子集（在同一业务域内）共享？ 对我而言，后者更有意义，因为它使更改，执行策略变得更加容易。它是DRY等。但是，通过各种将其规则转储到一个地方的服务，它也很容易失控，并且还担心网络开销。 有什么想法吗？

12 architecture  authorization  microservices 

我正在设计一个Web应用程序，并且想知道如何设计用于管理自动电子邮件发送的体系结构。 目前，我已将此功能内置到我的Web应用程序中，并且根据用户输入/交互（例如创建新用户）发送电子邮件。问题是直接连接到邮件服务器需要花费几秒钟的时间。扩大我的应用程序，这将是未来的重大瓶颈。 在我的系统体系结构中管理发送大量自动电子邮件的最佳方法是什么？ 不会发送大量电子邮件（每天最多20​​00个）。电子邮件无需立即发送，最多可以延迟10分钟。 更新：消息队列已作为答案，但是如何设计？是否可以在应用程序中处理并在安静的时间段进行处理，还是我需要创建一个新的“邮件应用程序”或网络服务来仅管理队列？

12 web-development  architecture  web-applications  web-design 

我了解两种架构之间的区别是哈佛架构中指令与数据的分离。但是我怎么知道我正在使用哪种类型的系统？是否可以编写程序确定该系统是冯·诺依曼还是哈佛？可能会存在另一种架构，或者仅是已知的这些架构？

12 architecture  computer-architecture 

因此，我一直在通过TDD创建数据访问层，并且有些担心。我宁愿不走错误的道路，所以我想让你们看看我的想法是否符合干净的体系结构。 我的数据访问层（简称DAL）中的方法非常简单。它们与数据库中的存储过程一致（没有其他方法可以使数据库保持干净），并且它们包含与存储过程相同的参数。然后，他们仅连接到数据库，并返回查询结果。这是一个例子： public int DeleteRecord(int recordId) { recordId.RequireThat("recordId").NotZeroOrLess(); List<SqlParameter> parameters = new List<SqlParameter>(); parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId}); return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray()); } 这对于这种类型的方法非常有效，因为我对结果集没有做任何有意义的事情。我只想确保命令有效，所以我将返回非查询的结果，该查询只是受影响的行，并且我可以使用该数字来验证逻辑。 但是，在另一种DAL方法中，我想加载一条记录。我的加载过程将selects针对一堆表执行并返回a DataSet，但是我正在努力解决DAL是否应该使用来在方法内创建Business Objects的问题DataSet，或者我的Business Objects本身是否应该具有Load()获取该方法的方法的问题。DataSet然后从DAL开始，然后基本完成 通过DAL进行操作会导致业务对象中的逻辑更少（即使这只是选择逻辑，仍然是逻辑），但是会使DAL有点拥挤，使人感觉它确实在做它不应该做的事情。做。 你们有什么感想？

12 c#  .net  architecture  database  business-logic 

开闭原理（OCP）指出对象应打开以进行扩展，但应关闭以进行修改。我相信我理解它，并将其与SRP结合使用来创建仅做一件事的类。而且，我尝试创建许多小的方法，使所有行为控件都可以提取到可以在某些子类中扩展或重写的方法中。因此，我最终得到了具有许多扩展点的类，包括：依赖项注入和组合，事件，委托等。 考虑以下简单的可扩展类： class PaycheckCalculator { // ... protected decimal GetOvertimeFactor() { return 2.0M; } } 现在说，例如，OvertimeFactor更改为1.5。由于上述类是为扩展而设计的，因此我可以轻松地子类化并返回一个不同的OvertimeFactor。 但是 ...尽管该类是为扩展而设计的，并且坚持使用OCP，但我将修改单个方法，而不是子类化和覆盖该方法，然后在IoC容器中重新连接对象。 结果，我违反了OCP尝试完成的部分工作。感觉就像是在偷懒，因为上面的内容要容易一些。我是否误解了OCP？我真的应该做些不同的事情吗？您是否以其他方式利用OCP的优势？ 更新：根据答案，由于许多不同的原因，这个人为的例子似乎是一个糟糕的例子。该示例的主要目的是证明该类是通过提供以下方法来扩展的：该方法在被重写时将更改公共方法的行为，而无需更改内部或私有代码。不过，我绝对误会了OCP。

12 design  design-patterns  architecture  object-oriented 

由于我习惯于采用单片方法，因此仍在尝试围绕微服务架构 假设我们尝试构建一个极其简化的 Uber预订系统。为简单起见，我们假设我们有3个服务和客户端的网关API： ，，Booking 和我们有以下流程：DriversNotification 创建新预订时： 检查现有用户是否已有预订 获取可用驱动程序列表 发送通知给司机以领取预订 司机接机 假设所有消息传递都是通过http调用完成的，而不是通过类似kafka的消息传递总线来完成的。 因此，在这种情况下，我认为该Booking服务可以对现有预订进行检查。但是，谁应该得到可用驱动程序和通知的列表呢？我正在考虑在网关级别执行此操作，但是现在逻辑可以分为两个地方： Gateway -获取可用驱动程序列表+发送通知 Booking -检查现有预订 而且我很确定网关不是正确的选择，但是我觉得如果我们在Booking服务中使用它，它将变得紧密相连吗？ 更复杂的是，如果我们有另一个项目想要重用预订系统，但又要有其自己的业务逻辑，该怎么办？这就是为什么我考虑在网关级别执行此操作，以便新项目网关可以将其自己的业务逻辑与现有逻辑分开。 我想的另一种做法是，每个项目都有自己的预订服务，该服务将与核心预订服务对话，但是我不确定这里最好的方法是什么:-)

12 architecture  microservices  business-logic 

我对以下术语感到困惑： 软件架构 软件应用程序体系结构是定义满足所有技术和运营要求的结构化解决方案的过程，同时优化了诸如性能，安全性和可管理性之类的通用质量属性。它涉及基于各种因素的一系列决策，并且这些决策中的每一个都会对应用程序的质量，性能，可维护性和整体成功产生重大影响。（微软） 系统架构 系统体系结构是概念模型，用于定义系统的结构，行为和更多视图。1体系结构描述是对系统的形式化描述和表示，以支持有关系统结构和行为的推理的方式组织（Wiki） 类图 在软件工程中，统一建模语言（UML）中的类图是一种静态结构图，它通过显示系统的类，其属性，操作（或方法）以及对象之间的关系来描述系统的结构。（维基） 如果我阅读了这些描述，所有这些都描述了应用程序不同模块之间的交互。但是，这些之间有什么区别？ 我认为/尝试比较这些术语： 类图不是系统体系结构的一种形式，因为上面的描述（structure, behavior, and more views of a system）暗示体系结构中不存在任何实现细节，而类图描述了实现，并且可能更倾向于设计而不是体系结构？ 我认为系统架构是还包括外部交互（如数据库）的架构，而软件架构则专注于应用程序本身？

11 design  architecture  class-diagram 

我看到洋葱架构仅比BL负责在DAL（或DAL的接口）上调用方法进行CRUD的3层架构有所益处。洋葱具有更好的关注点分离，可测试性，可维护性，并且更清洁。 那么，洋葱架构在各个方面是否确实更好，并且3层架构只是做事的一种旧方法，或者在某些情况下，我更喜欢使用3层架构，如果这样-哪个？

11 design  architecture  layers  n-tier  onion-architecture 

我们正在进行一个新项目，目前开发人员已分为两个团队，即团队A和团队B。该项目有两个部分，需要在整个开发堆栈中进行开发。堆栈的简化示例如下所示： 项目的每个部分都需要在整个堆栈上进行开发，因此我通常希望使用完整的堆栈开发人员方法，这就是我们如何分解团队B中的工作，设计和设计不同部分之间的交互的方式。 但是，我最近了解到，团队A要负责堆栈的某些部分，他们提议在两个团队之间进行划分，其中数据抽象层（并将内容放入数据层）由团队B没有任何发展。这种鸿沟看起来类似于： 对我来说，这感觉很不自然。每个团队都有不同的目标和时间表来实现这些目标，但是B团队将依赖于A团队来实现功能。提出的解决方案是预先定义通用接口（该项目可能需要2年的时间，因此可能会很多）。尽管有自己的目标，团队A仍将尽早为这些接口开发所需的位，而团队B则在短期内取消所有呼叫，以便他们继续前进。 我对此方法感到担忧： 接口可能会更改，并且组A可能没有带宽或时间来适应不断变化的需求。 A团队代码中的错误可能会阻止B团队前进，并且由于A团队的优先级队列不同，它们可能也不是解决这些错误的优先事项。 团队之间缺乏知识传播-团队B可能无法完全了解幕后情况，因此可能会做出糟糕的设计决策。 已经提出，该行业中的许多公司都有子团队，并且必须能够处理此问题。根据我的理解，通常团队会按照最初的期望进行拆分（全栈），或者通过如下分解技术栈： 因此，我有兴趣了解其他行业的情况。大多数拆分是垂直/水平的吗？对角线分割有意义吗？如果发生对角线分裂，我的担忧似乎是成立的，并且B团队还有其他需要关注的问题吗？请注意，我可能要对B团队的成功或失败负责。

11 architecture  programming-practices  development-process  team 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 我总是感到抽象机器（例如图灵机）和计算机体系结构（包括虚拟机的体系结构，冯·诺伊曼的体系结构）之间没有联系。所以我想知道它们之间的关系吗？一个如何影响另一个？参考文献也被赞赏。谢谢。

11 architecture 

我们正在开发两个相关的系统。其中一个（A）将安装在我们客户的机器上。其余（B）将由我的组织使用。 每个系统都有其自己的数据库（关系型），并且其架构也不同。但是，两个系统都必须同步。另外，必须将B中的某些更改导出到所有A类系统，而其他仅导出到特定的系统。 有些客户没有Internet连接，因此在某些情况下，必须通过交换文件来完成同步。 因此，我们正计划解决以下问题： 每个系统都维护其数据库的变更日志。我们计划用MongoDB实施它。 当系统初始化同步过程时，它将从日志中检索所有进行的更改。如果系统是B，则检索到的更改取决于目标。然后，系统以XML格式对它们进行序列化，最后（通过文件或网络）发送它们。 当另一端点接收到变更集时，它将对它们进行反序列化。然后，系统对数据进行一些必要的转换，最后记录所做的更改。在这一步中，如果有必要，系统必须解决可能存在的冲突。 最后，接收器系统发送其更改（以及其他解决冲突的产品）。 这种方法可行，可扩展且优雅吗？您将进行哪些更改或添加？

11 architecture  data  synchronization 

编码实际上并不难。困难的部分是编写有意义，可读和可理解的代码。因此，我想找一个更好的开发人员并创建一些可靠的体系结构。 因此，我想为电子游戏中的NPC创建一个体系结构。这是一个实时战略游戏，例如《星际争霸》，《帝国时代》，《命令与征服》等。因此，我将拥有不同种类的NPC。一个NPC可以有一对多的能力，这些（方法）： Build()，Farm()和Attack()。 例子： 工人可以Build()和Farm() 战士可以Attack() 公民可以Build()，Farm()和Attack() 渔民可以Farm()和Attack() 我希望到目前为止一切都清楚。 所以现在我有了我的NPC类型及其能力。但是让我们来谈谈技术/程序方面。 对于我不同种类的NPC，什么样的程序设计架构会很好？ 好吧，我可以有一个基础课。实际上，我认为这是坚持DRY原则的好方法。因此，我可以WalkTo(x,y)在基类中使用类似的方法，因为每个NPC都可以移动。但是现在让我们来解决真正的问题。我在哪里实现我的能力？（记住：Build()，Farm()和Attack()） 由于这些能力将由相同的逻辑组成，因此为每个NPC（工人，战士，..）实施它们将是令人讨厌的/打破DRY原则。 好吧，我可以在基类中实现这些功能。这将需要某种逻辑来验证NPC是否可以使用X IsBuilder，... CanBuild，…… 能力。我想我想表达的很清楚。 但是我对这个想法不太满意。这听起来像一个功能过多的。肿基类。 我确实使用C＃作为编程语言。因此，这里不能选择多重继承。意思是：拥有额外的基础类是Fisherman : Farmer, Attacker行不通的。

11 c#  architecture  multiple-inheritance 

原来的样子 多年以来，我一直在组织软件解决方案，例如： 数据访问层（DAL），用于抽象访问数据的业务 业务逻辑层（BLL），用于将业务规则应用于数据集，处理身份验证等。 实用程序（Util）只是我逐渐建立的常用实用程序方法的库。 表示层当然可以是Web，桌面，移动等。 现在的样子 在过去的四年左右的时间里，我一直在使用Microsoft的Entity Framework（我主要是.NET开发人员），并且由于Entity Framework已经完成了DAL工作，因此我发现拥有DAL变得越来越麻烦。我的DAL曾经做过的工作：它抽象了针对数据库运行CRUD的业务。 因此，我通常以一个DAL结束，该DAL具有如下方法的集合： public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 然后，在BLL中，该方法将按如下方式使用： public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } 当然，这是一个简单的示例，因为BLL通常会应用多行逻辑，但是在这样有限的范围内维护DAL似乎有点多余。 放弃DAL并像这样简单地编写我的BLL方法会不会更好： public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

11 architecture  data-structures  entity-framework  separation-of-concerns