Questions tagged «architecture»

假设在一次采访中被问到“您将如何实施Google搜索？” 您将如何回答这样的问题？可能有一些资源可以解释Google如何实现某些功能（BigTable，MapReduce，PageRank等），但这并不完全适合采访。 您将使用什么总体架构，以及如何在15-30分钟的时间内解释这一点？ 我将首先说明如何构建一个可处理约10万个文档的搜索引擎，然后通过分片扩展到约5000万个文档，然后再扩展一次体系结构/技术。 这是20,000英尺的视图。我想要的是细节-您在面试中如何实际回答。您将使用哪种数据结构。您的架构由什么服务/机器组成。典型的查询延迟是多少？故障转移/大脑分裂问题怎么办？等等...

44 design  algorithms  architecture  search 

的清洁体系结构建议让交互器调用实际执行的演示者（其被注入时，DIP以下）的处理响应/显示的用例。但是，我看到人们实现了这种体系结构，从交互器返回输出数据，然后让控制器（在适配器层中）决定如何处理它。除了没有明确定义交互器的输入和输出端口之外，第二种解决方案是否将应用程序职责泄漏到应用程序层之外？ 输入和输出端口 考虑到Clean Architecture的定义，尤其是描述控制器，用例交互器和演示者之间关系的小流程图，我不确定我是否正确理解“用例输出端口”应该是什么。 像六边形体系结构一样，干净的体系结构区分主要端口（方法）和次要端口（由适配器实现的接口）。按照通信流程，我希望“用例输入端口”是主要端口（因此只是一个方法），而“用例输出端口”是要实现的接口，也许是使用实际适配器的构造函数参数，以便交互器可以使用它。 代码示例 举例来说，这可能是控制器代码： Presenter presenter = new Presenter(); Repository repository = new Repository(); UseCase useCase = new UseCase(presenter, repository); useCase->doSomething(); 演示者界面： // Use Case Output Port interface Presenter { public void present(Data data); } 最后，交互器本身： class UseCase { private Repository repository; private Presenter presenter; public UseCase(Repository …

42 architecture  architectural-patterns  onion-architecture 

在非敏捷开发团队中，首席开发人员通常： 设置标准（编码等） 为团队研究新技术 为团队设定技术方向 对事情有最终决定权 设计系统架构 但是，敏捷团队的工作方式有所不同： 敏捷团队将依靠紧急设计，而不是预先设计 敏捷团队一起设计，而不是由一个人决定设计 敏捷团队决定自己的技术方向，这是交付项目的最佳选择 这将使敏捷开发团队中的首席开发人员离开哪里？在敏捷团队中是否可能有首席开发人员？敏捷团队是否需要与领导不同的职责？

42 design  architecture  agile  scrum  team-leader 

我是一名初级开发人员（约3年经验），在我的工作中，我们正在设计一个新系统。我的首席开发人员将是首席架构师，但是他向我提出挑战，要求我自己（并行）架构系统。 在反复集思广益的想法并提出我认为是架构建议的过程中，我的领导给了我反馈，我所做的大部分工作都是“设计”而不是“架构”。 他将差异描述为架构与实现无关，而设计是对实现的描述。他说我需要脱下设计师的帽子，戴上建筑师的帽子。他给了我一些建议，但我也想问你： 如何摆脱软件设计师模式，开始像架构师那样思考？ 以下是我提出的一些“设计” 示例，这些示例被我的领导认为与架构无关： 我想出了一种用于从系统中加载和卸载资源的算法，我的负责人说算法绝对不是体系结构。 我想出了系统应该引发的一系列事件以及应该以什么顺序引发它们，但是这似乎也没有将其视为架构。 我似乎陷入了细节之中，没有退后一步。我发现，即使我提出的是体系结构级别的内容，我也经常通过尝试各种实现并仔细研究细节，然后进行概括和抽象来达到目标​​。当我向我的领导描述时，他说我采用了错误的方法：我需要思考的是“自上而下”而不是“自下而上”。 这里是有关该项目的一些更具体的细节： 我们正在设计的项目是一个Web应用程序。 我估计大约有10到10万行代码。 我们是一家初创公司。我们的工程团队大约3-5人。 我可以将应用程序与之最接近的是轻量级CMS。它具有类似的复杂性，并且主要处理组件的加载和卸载，布局管理以及插件样式的模块。 该应用程序是ajax-y。用户一次下载客户端，然后根据需要从服务器请求数据。 我们将使用MVC模式。 该应用程序将具有身份验证。 我们不是很在意旧的浏览器支持（哇！），因此我们希望利用现有的最新和最大的支持。（HTML5，CSS3，WebGL ？、媒体源扩展等等！） 这是该项目的一些目标： 应用程序需要扩展。在不久的将来，我们的用户数量将达到数百至数千，但我们正在计划数以万计至数百万甚至更多。 我们希望该应用程序永远存在。这不是临时解决方案。（实际上，我们已经有了一个临时的解决方案，而我们正在设计的是长期替代现有的解决方案）。 该应用程序应该安全，因为它可能与敏感的个人信息联系在一起。 应用程序必须稳定。（理想情况下，它在gmail级别左右是稳定的，但不必在火星漫游者的极端位置。）

42 design  architecture 

我最近遇到了一个看似微不足道的建筑问题。我的代码中有一个简单的存储库，其名称如下所示（代码在C＃中）： var user = /* create user somehow */; _userRepository.Add(user); /* do some other stuff*/ _userRepository.SaveChanges(); SaveChanges 是一个简单的包装程序，用于将更改提交到数据库： void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); } 然后，过了一段时间，我需要实现新的逻辑，该逻辑每次在系统中创建用户时都会发送电子邮件通知。由于有许多来电_userRepository.Add()和SaveChanges系统的时候，我决定更新SaveChanges如下： void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); foreach (var newUser in dataContext.GetAddedUsers()) { _eventService.RaiseEvent(new UserCreatedEvent(newUser )) } …

40 architecture  single-responsibility  event 

我正在设计一个RESTful API。我们知道我们想为任何给定资源返回JSON和XML。我一直在想我们会做这样的事情： GET /api/something?param1=value1 Accept: application/xml (or application/json) 但是，有人为此使用扩展名，就像这样： GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1) 这些方法的权衡是什么？未指定扩展名时最好依靠accept标头，但在指定扩展名时依靠荣誉标头吗？这种方法有缺点吗？

40 architecture  web-services  rest  http 

我已经在一家大公司（拥有8000多名员工）工作了将近2年，而在我完成学习课程后才被录用。 这里的每个人都必须每天处理遗留代码，这些遗留代码通常设计得很糟糕并且充满了骇客。首先，我保持低调，尽量不要批评太多。但是，从目前的情况来看，这种情况已经变得很难适应，而且似乎没有人愿意改进/替换我们使用的工具。 更明确地说，我们有： 过时的源代码控制工具（Visual SourceSafe） 普通的旧makefile，仅支持完全重建 .def 所有现有体系结构必须手动维护的文件 整体头文件和包含很少文件的项目（但每个头文件都有大约3000行代码，有时需要处理非常不同的任务） 不使用“新”语言工具（std::string不是新语言，但除我以外没有人使用它） 几个月前，我决定通过设计一个新的编译环境来对此做一些事情。我可以使增量构建可靠地工作，更快的编译时间，更好的结构化项目，自动.def文件生成。我什至还创建了一个从Git到Visual SourceSafe的桥梁。 我向几位同事和我们的老板展示了我的成就，但没人关心。他们都像“嗯...人们现在已经习惯那样做了。我们为什么要改变事情？” 我建议的更改是为了使我们能够从旧系统到新系统的一个软过渡而设计的。每个改进都可以单独安全地应用。 我什至试图让我的一些同事参与到变更中。但是到目前为止，还没有成功。 您是否已经遇到过类似情况？如果“以身作则”无效，该怎么办？

40 architecture  productivity  changes 

我正在研究我正在开发的应用程序的体系结构模式，微服务方法似乎是一个不错的选择，但是我不确定如何处理服务之间的交互。 该应用程序主要处理用户，用户拥有的配置文件，照片以及代表照片中一对多配置文件的标签。可以想象有一些方法可以返回用户上传的照片，返回包含特定标记个人资料的照片，等等。 这是我设计基于微服务的体系结构的第一步，而我来自于启发式历史的整体式域模型。在那个世界中，控制器会将这些域对象缝合在一起，但是我很难理解如何以微服务方式工作。

39 architecture  web-applications  domain-driven-design  microservices 

在构建非平凡的应用程序时，最好集中精力使事情快速运行，并在代码中采取一些捷径，例如将模型逻辑与视图混合，破坏封装-典型的代码味道？或者，您是不是最好花些时间来构建更多的体系结构，正确构建它，但是冒着这样的风险，因为您的设计非常流畅，所以可能无法使用所有这些额外的代码，并且如果反馈导致您可能不得不将其丢弃去一个不同的方向？ 对于上下文，我正在构建一个桌面应用程序。我是唯一的开发人员，因为我有一份日常工作，所以我做兼职。现在，在工作中，我会尽量按计划安排正确的方式做事。但是对于这个项目，我希望它会随着人们的反馈而变化，我不确定这是正确的方法。我本周花了几个小时在适当的地方放置了教科书“模型视图控制器”设计，以将模型中的更改传达给视图。总的来说，这很好，但是我不确定是否需要多个视图来显示数据，而且我知道如果没有其他体系结构，我可以更快地显示内容。我可能每周花10到15个小时花在该项目上，如果遵循良好的软件实践，我会花很多时间来构建可以演示的东西。我知道我的用户会 不在乎我在内部使用MVC，他们只是想要解决问题的方法。但是我也遇到过这样的情况，即您因快捷方式而承担了太多的技术债务，以至于很难维护代码并添加新功能。我很想听听其他人如何解决这种问题。

38 design  architecture  quality 

我在一个项目中工作，该项目使用（Spring）依赖注入来处理实际上是类依赖的所有内容。我们现在已经将Spring配置文件增加到大约4000行。不久前，我观看了Bob叔叔在YouTube上的一次演讲（不幸的是，我找不到该链接），在该演讲中，他建议仅将几个中央依赖项（例如工厂，数据库等）注入到Main组件中，然后从它们分布。 这种方法的优点是将DI框架与应用程序的大部分解耦，并且还使Spring配置更干净，因为工厂将包含以前配置中的更多内容。相反，这将导致创建逻辑在许多工厂类之间传播，并且测试可能会变得更加困难。 因此，我的问题确实是，您会在一种或另一种方法中看到哪些其他优点或缺点？有没有最佳做法？非常感谢你的回答！

38 architecture  dependency-injection 

大多数时候，我将开发应用程序配置存储在项目的根目录中，如下所示： app |-- config.json 但这似乎不是最佳方法，因为此配置最终存储在版本控制系统中-可能导致用户名，密码和其他敏感内容泄漏。 12 Factor App指南建议完全删除配置文件，并使用环境变量进行配置设置： ...将配置存储在环境变量中。Env var易于在部署之间进行更改，而无需更改任何代码。与配置文件不同，它们很少有可能被意外检入代码存储库；与自定义配置文件或其他配置机制（例如Java系统属性）不同，它们是与语言和操作系统无关的标准。 这对我来说听起来真的很不错，但是在没有将其检入源代码管理的情况下，该变量存储在哪里呢？我可以使用哪些工具将这些变量传递给应用程序？可能有数十种配置选项，每次启动应用程序时手动键入它们都不是一件好事-因此它们必须存储在某种文件中。这样，该文件将最终在源代码控制中，然后我们返回到开始的地方。 是否有一些公认的处理配置选项的方法，而没有将本地配置存储在源代码管理中的风险？

38 architecture  configuration  configuration-management 

根据Microsoft文档，有关Wikipedia SOLID原则的文章或大多数IT架构师，我们必须确保每个班级仅负一个责任。我想知道为什么，因为如果每个人似乎都同意这条规则，那么似乎没人会同意这条规则的原因。 一些人引用了更好的维护，有人说它提供了简单的测试，或者使类更加健壮或安全。什么是正确的，实际上是什么意思？为什么它可以使维护更好，测试更容易或代码更健壮？

37 design-patterns  architecture  solid  single-responsibility 

我曾经创建许多抽象类/方法。然后我开始使用接口。 现在，我不确定接口是否不会使抽象类过时。 您需要一个完全抽象的类吗？创建一个接口。您需要一个带有一些实现的抽象类吗？创建一个接口，创建一个类。继承该类，实现接口。另一个好处是某些类可能不需要父类，而只实现接口。 那么，抽象类/方法是否过时了？

37 object-oriented  architecture  inheritance  interfaces 

Web上有大量参考和列出代码气味的资源。但是，我从未见过有关建筑异味的信息。这是在某处定义的，并且有可用的列表吗？是否已对架构缺陷及其对项目速度，缺陷等的影响进行了正式研究？ 编辑：我并不是真正在答案中寻找清单，而是有关建筑气味的文档（在网络上或书籍中）。

37 architecture  code-smell  quality 

很多很多月以前，我做过面向对象软件工程的硕士。我涵盖了所有内容：项目启动，需求，分析，设计，体系结构，开发等，等等。我一直以来最喜欢的IT书籍是《开发面向对象的软件》，这是一种基于经验的方法（IBM-1996）。由一群当时的真正专家创作的书。它描述了以工作产品为中心的方法来进行面向对象的分析，设计和开发方法。 我设计和开发游戏时感到很开心，并在游戏中处于顶峰，但我开始感到有些过时：敏捷运动已成为当今的时尚，并用新的时髦词重新命名了一些众所周知的迭代和增量方法。当我说“需求”或“架构”时，经验不足的开发人员开始皱眉，好像这些东西已被魔术所取代。 设计和开发失去了乐趣，我将把整个IT行业抛在身后。 然后我发现了Scala。哦，就像尘土飞扬的道路上的小雨。一切都变得清晰起来，空气再次变得甜美起来，硬盘驱动器上的微弱灯光将闪烁到深夜，使我开心地陪伴在发现世界中。 我喜欢系统设计。我是一名建筑师，而不是程序员。我喜欢分析，设计，思考，争论，改进-我只是喜欢简单，干净和清晰的设计。 我们如何设计纯Scala解决方案？ 当然，常规命令图，交互图，对象图等都可以全部替换或改进，以将命令性和功能性面向对象的系统融合在一起。当然，有一个完全不同的地方可以开放！ 我不是在寻找肿的复杂性，而是在寻找灵活的简单性。实际上，Scala很简单（虽然有所不同），但可以像一条瑜伽裤一样扩展以适应您的需求。对于这种可爱的语言，必须有一个设计系统，该系统应从简单开始，并且可以扩展以适合您的要求和您的领域。当然不能是UML！ 那么我们如何设计纯Scala系统呢？想象一下，您有足够的勇气从头开始设计一个完整的系统，并且知道您将只使用Scala- 您的模型外观如何？您必须描述什么类型的图的结构和行为？您将如何对选项，匹配项，混合项，单例对象等进行建模，而不会陷入扩展现有建模技术而不是使用新颖，轻巧的创新工具集的复杂性。 是否存在这样的设计/过程/解决方案，或者现在该发明一个？

35 scala  architecture