Questions tagged «enterprise-architecture»

我为金融/保险行业的一家大型企业（雇员3万）工作。虽然“ IT”不是我们的主要重点，但老实说，这些都是信息驱动的行业，具有更好技术优势的公司似乎能更快地取得发展。 我公司有很多软件开发团队。它们遍布整个版本，具有版本控制功能，更不用说使用的语言/框架了。有些人不使用任何（我知道），一些人使用PVCS，一些人使用VSS，最开明的人使用SVN。 我想将git带入我的企业。更具体地说，我想引入GitHub（私有存储库）。我知道合适的人可以谈论这个话题，但老实说，由于诸如安全隐患或我们的竞争对手都没有使用它这样的大举动作，通常在大型企业环境中会被击落。仅引用jQuery，Ruby on Rails，Facebook等作为参考）。 所以我的问题是这个。大型企业为何应缓慢而有意识地从PVCS / VSS / SVN切换到托管git解决方案（如GitHub，私有仓库）的最令人信服的原因是什么。当然，我的计划的一部分涉及到一个不必要的开发项目的POC。

12 version-control  git  github  enterprise-architecture 

云计算是否足够成熟，可以减轻在现场维护IT基础架构的烦恼？如果是这样，采用它有哪些缺点？安全和隐私是一个大问题吗？

12 cloud-computing  enterprise-architecture 

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

12 design  architecture  enterprise-architecture  microservices  business-rules 

两种企业集成模式是命令消息和事件消息。我正在开发一个系统，在该系统中，我们不仅使用消息传递与其他系统集成，还使用服务之间的内部通信。它应该是一个最终一致的系统，并且服务应该彼此一无所知（几个特殊用途的服务除外）。因此，我们尽量避免感觉像是远程过程调用（RPC或RPI）。我们有一个面向总线和面向消息的中间件系统，并且所有消息都被广播。 我们倾向于将消息命名为事件，即过去完美的短语，例如PurchaseOrderShipped。但是，通常仅在某些其他服务需要了解事件时才添加事件，并且一开始通常只关心一个服务。而且，有时该服务会发出一个结果，该事件会被第一个服务侦听。因此，如果我要绘制交互关系图，则它看起来更像是上面链接中的命令消息图（甚至是RPC图），而不是事件消息图，尽管这实际上并没有实现直接消息传递，但在公交车上广播。另外，我最近看到有一些消息被添加为命令，即命令中的短语，例如BillShippedPurchaseOrder。 奇怪的是，消息的名称及其传递方式不会通过将其命名为事件还是命令而改变。那么，如何确定某个东西应该是命令消息还是事件？这仅仅是语义和命名的区别，还是命令和事件消息之间的实际实现区别？既然我们所有的消息都是广播的，那是否意味着没有一个是真正的命令消息？

11 enterprise-architecture  messaging  event  command-message 

我看到“企业”一词在软件开发人员和程序员中泛滥，似乎松散使用。 恩·特普里斯/ ˈentərˌprīz / 名词：项目或事业，通常是困难的或需要努力的。主动性和机智。 有人可以澄清一下这个术语的实际含义吗？“在企业层面”，“企业规模”？甚至有“企业版”的东西。这到底是什么意思？从上述定义来看，显然没有任何意义，因此更具体地讲软件对企业一词的含义是什么？ 编辑： 要对此进行补充，该术语又如何适合诸如Enterprise Framework Model之类的短语？数据访问和数据上下文与公司范围的描述有什么关系？

11 enterprise-architecture  enterprise-development  language-discussion 

我想知道是否有人成功将Windows Workflow Foundation用于BusinessRules / Validation引擎，或者您是否知道一些示例代码或与此相关的文章。 如果您曾经使用过它，您怎么看？与其他BusinessRule / Validation系统相比如何？ 我在想类似的规则 if (A, B, and C) AllowAccess(); 要么 if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

免责声明 我希望我不要踩任何人的脚趾或冒犯任何一个概念的狂热者 背景 我一直在寻找面向服务的体系结构和微服务之间的真正区别，而没有找到明确的答案。 我读到以下内容： SOA的副作用 SOA是反模式 微服务来修复SOA的故障 ESB并不是真正的ESB，而是EAI 对消息中介的过度依赖 供应商正在滥用SOA的概念并试图出售其产品 SOA不受控制地增长 但是，仍然没有明确定义面向服务的体系结构（作为一个概念）和微服务（作为一个概念）之间的体系结构差异 据我了解，它们都具有： 服务提供商，只做一件事 服务网关/ ESB将这些服务提供给消费者 服务使用者，通过ESB /服务网关访问服务 题 那么，除了将SOA重新标记为微服务之外，还有什么不同吗？限制微服务成为宏的技术约束吗？ 注意：我不是在寻找观点，只是在寻找事实，希望在要点中 参考文献 软件工程问题 马丁·福勒（Martin Fowler）的网站（我认为他讨厌这段时间） 信息世界 迈克尔·富瑟斯的网站 堆栈溢出问题 更新资料 似乎在Stack溢出问题中也发生了类似的辩论，无论是否区分微服务都是变相的面向服务架构。 SO问题的结论： MS是SOA 的特例 MS支持较小规模的应用程序托管服务 MS取决于技术（使用HTTP而非开放协议选项） MS依靠技术来加强纪律（服务的自动部署） MS考虑使用ESB（邪恶），但使用API​​网关，IMHO是ESB的一种 如果满足以下条件，那么可以得出结论，MS是SOA： MS是否支持编排概念？一个或多个主流程管理工作流程 MS中是否有消息代理层？一组适配器，将消息格式从服务生产者的消息空间转换为服务使用者 微服务可以从整体企业应用程序读取数据吗？可以是单片应用程序的API吗？还是必须是能够独立运行的独立的自包含应用程序？ 如果最后一个问题的答案为否，那么微服务将无法处理复杂的工作流程系统，例如信用卡管理系统或对帐系统

10 microservices  enterprise-architecture  soa 

我没有使用任何缓存机制，并且想知道在以下情况下我在.net世界中的选择是什么。 我们基本上有一个REST服务，其中用户传递类别的ID（思考文件夹），并且此类别可能有很多子类别，每个子类别可以具有1000个媒体容器（思想文件引用对象），其中包含有关以下内容的信息可能位于NAS或SAN服务器上的文件（在这种情况下，文件是视频）。这些类别之间的关系与一些权限规则和有关子类别的元数据一起存储在数据库中。 因此，从UI角度来看，我们有一个惰性加载的树控件，该控件由用户通过单击每个子文件夹来驱动（以Windows资源管理器为例）。他们进入视频文件的URL后，便可以观看视频。 随着系统的发展，用户数量可能会增长到1000，而子类别和视频的数量可能会在10000。 问题是我们应该在每个请求访问数据库的地方继续当前的工作方式，还是应该考虑缓存数据？ 我们正在使用IIS 6/7和Asp.net。

10 design  architecture  asp.net  enterprise-architecture  iis 

我的公司正在从头开始重写我们的Web应用程序。它是大型企业级应用程序，在金融行业中具有复杂的领域。 我们使用ORM（实体框架）进行持久化。 本质上，我们的应用程序的一半集中在从用户那里收集原始数据，进行存储，然后包含大部分实际域逻辑的应用程序的另一半使用原始数据来创建我们的域图片，该域图片与原始数据有很大的不同原始输入，并将其传递到calc引擎，运行calcs，并吐出结果，然后将结果显示给用户。 在使用层的DDD方法中，CRUD操作似乎遍历域层。但至少在我们看来，这似乎没有道理。 例如，当用户转到编辑屏幕以更改投资帐户时，屏幕上的字段是存储在数据库中的确切字段，而不是以后用于计算的域表示形式。那么，当编辑屏幕需要数据库表示形式（原始输入）时，为什么要加载投资帐户的域表示形式呢？ 在用户单击投资帐户屏幕上的“完成”，并对控制器执行POST之后，控制器现在几乎具有需要保存的投资帐户的确切数据库表示形式。但是出于某种原因，我应该加载域表示以进行修改，而不是仅将控制器模型直接映射到数据库模型（实体框架模型）？ 因此，从本质上讲，我是将数据模型映射到域模型，以便可以将其映射回数据模型以持久化。这有什么意义？

9 design-patterns  object-oriented-design  domain-driven-design  enterprise-architecture 

现代程序中流行的高级体系结构选择是基于REST的微服务系统。这具有几个优点，例如松耦合，易于重用，对可用技术的限制有限，高可伸缩性等。 但是我预见到的这种架构中的问题之一是对应用程序依赖项的可见性不佳。例如，假设我有一个应用程序，该应用程序每天使用一组REST调用。该应用程序还使用第二组REST调用，但每季度仅使用一次。如果我要扫描过去一周的日志，我会看到所有的每日校准数据，但可能看不到季度调用。当需要重构时，每季度调用的中断风险很高。 可以使用什么模式或工具来减少这种风险，并提供对松散耦合体系结构的依赖性的更大可见性？

9 architecture  rest  enterprise-architecture  microservices  coupling 

在软件架构和设计方面，微服务如何与中间件“堆叠”（双关语意）？我来自Java，似乎当您摆脱作为API的直接REST并抽象出不同的层和连接参数时，至少在Java中，您几乎已经完全回到了一些非常古老的想法。我们已经回到虚拟化……而JVM 已经是虚拟的。 以一种不可知论的方式，您可以并且我会争论将RESTful API抽象到CORBA的优点。或者，以Java为中心的方式，使用JMS或MDB。 EJB在Java上曾经是一个大问题，但在某种程度上它被认为是集群效果，但是现在，我们又回到了起点吗？ 还是微服务提供了CORBA甚至更好的MDB所缺少的功能？当我读（TLDR）Martin Fowler解释微服务时，如果可以的话，它是解决一个严重问题的很好的解决方案。更确切地说，是一种封闭的方法，它引入了一定程度的复杂性，只能解决问题。如果这些服务确实是微服务，并且数量众多，则每个服务的运行和维护成本都为一美元。 此外，如果许多微服务中的一个微服务更改了其API，那么依赖该服务的所有内容都会中断。它并不显得松散连接，它似乎敏捷的对立面。还是我滥用这些话？ 当然，在这些极端之间有很多不确定的选择。 鲨鱼与大猩猩...走吧！ （对于书呆子来说，这具有讽刺意味，完全不是我的意图。这个问题是从表面上考虑的。如果这个问题可以改善，请这样做，或者发表评论，我会解决的。 ） 设想在docker上运行的多个微服务都在一台机器上互相交谈...疯狂。难以维护或管理，几乎不可能更改任何东西，因为任何更改都会级联并导致不可预见的错误。这些服务分散在不同的计算机上如何更好？而且，如果它们是分布式的，那么肯定可以解决某些非常非常古老的技术，至少在一定程度上解决了分布式计算的问题。 为什么水平缩放如此普遍，或者至少是可取的？

9 java  enterprise-architecture  distributed-computing  client-server  middleware 

我公司正在考虑将其所有的第1层（即高端生产）应用程序和站点整合到一个包含所有内容的代码库中。 从理论上讲，它们的权限，设计和整体功能可以同质化并集中管理。 我无休止地担心这种方法，因为支撑每个应用程序的数据结构是非常不同的，业务规则是复杂的，并且对于每个应用程序都是唯一的，并且现有应用程序的整体代码库是极为不同的，并且非常被忽略。 编辑： 当前环境由三个ASP.Net 1.1站点和一个MVC2应用程序组成，这三个站点自首次编写以来就几乎没有任何真正的热爱（主要原因是公司中没有经验丰富的开发人员），而另一个MVC2应用程序在成为ASP.Net 1.1站点之前去年升级。我们只用C＃编写。 该公司规模很小，只有大约50名员工。其中三个是实际的开发人员。管理（甚至是IT管理）除了具有IT项目的项目管理（因此具有一定的术语和业务影响知识）以外，没有任何IT背景或经验。 这些应用程序主要是在线服务，用于支持公司出售的产品。该公司不直接出售任何软件。 因此，用一个合理而具体且可以回答的问题来表述整个情况：在当前条件下（例如，旧代码库，复杂的业务系统和规则），有哪些令人信服的理由支持和反对将所有系统整合到一个总体解决方案中？ ）？

9 asp.net  enterprise-architecture 

我们的团队最初由大多数服务器端开发人员组成，他们只具备Javascript方面的最少专业知识。在ASP.NET中，我们过去经常在代码背后或通过MVC中的控制器编写许多UI逻辑。 不久前，有2位高级客户端开发人员加入了我们的团队。他们可以在HTMl / CSS / Javascript中完成我们以前使用服务器端代码和服务器端Web控件可以做的几乎所有事情： 显示/隐藏控件 做验证 控制AJAX刷新 因此，我开始认为，围绕我们的业务逻辑创建一个高级API可能会更有效，例如Amazon Fulfillment API：http : //docs.amazonwebservices.com/fws/latest/APIReference/，以便该客户端端开发人员将完全接管UI，而服务器端开发人员将仅专注于业务逻辑。 因此，对于订购系统，您将拥有一个高级API，例如： OrderService.asmx CreateOrderResponse CreateOrder(CreateOrderRequest) AddOrderItem AddPayment - SubmitPayment - GetOrderByID FindOrdersByCriteria ... 可以通过JSON / REST访问API，因此很容易从客户端UI中使用。我们可以使用此API进行内部UI开发，也可以让第三方使用此API创建自己的应用程序。 随着Javascript的发展以及优秀的客户端开发人员的可用性，现在是否是摆脱代码隐藏/控制器并仅专注于开发客户端开发人员可以使用的高级API（阿拉玛）的好时机？

9 javascript  architecture  asp.net  team  enterprise-architecture