Questions tagged «enterprise-architecture»

我在一家构建企业应用程序的公司工作，并且维护三个环境：开发（或dev），暂存（或stage）和生产（或prod）。 dev的含义很直观：这是在应用程序开发期间使用的环境。 暂存和生产环境之间有什么区别？

80 enterprise-architecture  java-ee  enterprise-development 

我正在使用具有1000多个表，另外几百个视图和几千个存储过程的SQL Server数据库。我们希望开始在新项目中使用Entity Framework，并且正在制定策略。我最想知道的是如何最好地将表拆分为不同的模型（如果我们先编写代码，则为EDMX或DbContext）。我可以马上想到一些策略： 按模式拆分 我们将表拆分成大概十二种模式。我们可以为每个架构创建一个模型。但是，这并不是完美的，因为dbo最终仍然非常大，具有500多个表/视图。另一个问题是，某些工作单元最终将不得不进行跨越多个模型的事务，这增加了复杂性，尽管我认为EF使这一过程变得相当简单。 按意图 拆分模型不必担心架构，而是按意图拆分模型。因此，对于每个应用程序，项目，模块，屏幕，我们将具有不同的模型，具体取决于我们希望获得的粒度。我看到的问题是，在某些情况下不可避免地要使用某些表，例如User或AuditHistory。我们是将它们添加到每个模型中（违反我认为的DRY），还是将它们添加到每个项目使用的单独模型中？ 完全不要分裂-一个巨大的模型 从开发的角度来看，这显然很简单，但是从我的研究和我的直觉来看，这似乎可以在设计时，编译时和运行时都表现出色。 在如此大的数据库上使用EF的最佳实践是什么？具体来说，人们在针对大量数据库对象设计模型时会使用哪些策略？是否有我没有想到的选项比上面的选项更好？ 另外，这在诸如NHibernate的其他ORM中是否存在问题？如果是这样，他们是否提出了比EF更好的解决方案？

50 entity-framework  orm  enterprise-architecture 

我不了解“普通”软件和企业软件之间的区别。即使阅读这些... Wikipedia上的“企业软件” Techcrunch上的“企业软件再次变得性感” 关于编码恐怖的“伟大的企业软件骗局” 我实在无法绕开真正的分歧。两者之间有什么区别吗？人们为什么说企业软件很烂？

46 terminology  enterprise-architecture 

我一直在阅读/观看Robert C. Martin的很多内容。我碰到他说，由于固态硬盘，SQL是不必要的。当我搜索其他资源以进行备份时，我会收到大量随机文章，描述硬盘驱动器和固态驱动器之间的SQL性能差异（相关但与我要研究的内容无关）。 最终，我不明白他在试图达到什么目的。他是说用No-SQL技术取代SQL吗？他是说在文件系统中的文件中存储数据吗？还是他只是希望人们因为SQLi攻击而停止使用SQL /关系数据库？我担心我错过了他想表达的观点。 我将在此处提供一些链接，以便您可以直接从他的心中读懂： 鲍比表 清洁建筑讲座 首先，他指出应该从系统中完全删除SQL。 解决方案。唯一的解决方案。是从系统中完全消除SQL。如果没有SQL引擎，那么就不会有SQLi攻击。 并且尽管他谈论使用API​​替换SQL，但我不认为他的意思是将SQL放在API后面，因为前面的引用以及他在本文前面所说的。 框架无法解决问题； ... 旁注：在说SQL时，我很确定Robert意味着大多数关系数据库。也许不是全部，而是大多数。无论如何，大多数人还是使用SQL。所以... 如果不使用SQL来持久化数据，那么我们应该使用什么呢？ 在回答之前，我还应该注意。罗伯特（Robert）强调，固态驱动器应该改变我们用来持久化数据的工具。SørenD.Ptæus的回答指出了这一点。 我还必须回应“但是数据完整性”组。经过进一步研究，罗伯特说我们应该使用像datomic这样的事务数据库。然后，CRUD变成CR（创建和读取），并且SQL事务完全消失。数据完整性当然很重要。 我找不到涵盖所有这些的问题。我想我正在寻找符合罗伯特指南的替代方案。Datomic是一个，但是是吗？还有哪些其他选项与这些准则匹配？它们在固态驱动器上是否更好地工作？

45 architecture  enterprise-architecture  architectural-patterns  plugin-architecture 

我正在提议对一个架构很差的软件项目进行更改，该项目会遇到很多问题。在较高的层次上，该项目在前端使用了Angular，并使用了各种REST API。一切都很棒（我看不到需要更改我们的技术或工具）。问题在于，UI中的代码库比服务器端API大得多。大多数业务逻辑都存在于UI中，而REST API是与UI层的简单CRUD数据库接口。 例如，发给客户的POST将创建客户记录，而PUT将修改该客户。不多，也不少。但是，我们的业务逻辑要求更高。创建客户的一般过程所要做的不仅仅是插入1条数据库记录。它将在其他必要的表中提供数据，执行某些验证和计算等。我更愿意进行单个POST / PUT调用来封装所有这些行为，从而减轻使用方客户端的负担。 因此，我的观点是，这种总体编排应该驻留在服务器（我们拥有完全控制权，日志等）上，而不是UI上，但是一个反对意见是该方法将不再是RESTful。因此，当我的建议是继续使用现有的技术堆栈，但在代码所属的位置实现根本的转变时，我不确定如何最好地描述这种方法。

37 rest  api-design  enterprise-architecture 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 在“企业”环境中，我注意到对专有软件的强烈偏见。即使在使用Java的大型企业中，也很难找到MySQL或PostgreSQL，并且WebSphere和WebLogic绝对比JBoss或Tomcat更受青睐。 这是可以理解的。尽管许多开发人员更喜欢Tomcat或Postgres而不是WebSphere或Oracle DB，但他们并不是最终决定这些事情的人。谁决定在生产中使用哪个数据库和应用程序服务器，谁就会发现，与选择导致真正，确实，糟糕的事情发生的自由软件相比，许可证费用似乎很小。 我不是在问Postgres是否和Oracle一样好。那不是重点。在仔细考虑功能和基准之后，Oracle不会被Postgres选中。Postgres不会进入对话，因为某些地方不信任自由软件。 我很好奇这种不信任是否是由于对任何特定事件的反应而引起的。所以我的问题是：是否有任何证明是由于开源软件缺陷导致的业务灾难（故障，收入严重损失，公司数据严重损失等）的记录在案？ 说明：如果您有完全支持OSS的企业级公司的经验，这些公司必须对此事存有偏见，但要根据特定情况的需要进行选择，那么对您有好处！您的经验并不会改变其他企业公司的态度完全不同的事实，即使这些公司占少数，我的问题也是有效的。

21 open-source  business  enterprise-architecture  failure  proprietary 

经过3个月的辩论和研究，关于在React（与Redux）和Angular 2之间进行选择的研究，我公司的前端团队最终决定采用Angular 2（因为它更适合我们的问题）。 我们正在从事企业应用程序业务，该业务目前由许多不同的前端技术组成（同时拥有整个后端RESTful），我们希望将其全部替换，并拥有一种技术来简化将来的培训和质量控制。 鉴于我们产品的性质，产品范围很广，并且其中包含模块，这些模块本身是不同的域，可以作为独立的应用程序制作，但产品本身位于单个URL中。 例; 我们将我的产品称为SuperApp。 作为UI，SuperApp具有标准的登录系统，并可以导航到子模块/子产品，因此工作流如下所示。 超级应用 验证用户 忘记密码向导 无需身份验证即可访问公共页面 认证用户 导航系统 家 子产品1 子产品2 子产品3 轮廓 ... ... 团体 ... ... 请注意，在以上表示中，Sub-product1和Sub-product2是两个完全不同的领域，具有完全不同的业务领域。 我现在可以想到的是，我可以将SuperApp创建为单个Angular 2项目，仅包含与其自身相关的组件和视图，并且SuperApp还负责加载多个子应用程序；Sub-product1，Sub-product2（同样是不同的Angular 2项目，它们都有自己的package.json，webpack配置等）通过哑组件，并充当提供顶级路由的Shell和占位符来容纳这些子应用。 有一次，Sub-product1在壳体内加载时，它会自己的路由附加到当前路由SuperApp在已经登陆。 我想要分离的原因是因为这些不同的应用程序（当前使用ExtJS构建）具有专门的团队（我们是一家拥有500多个开发人员的公司），因此，如果他们拥有自己的Angular项目，则可以管理其工具并依赖于他们的喜好，而无需依赖父级父级应用。 但是我无法在官方的Angular文档中或网上找到任何地方是否可以嵌套Angular应用程序（以这种方式共享框架代码，而完全隔离子应用程序的依赖项并仅在应用程序加载时需要），或者是否有其他替代方法可以解决此问题。 任何指导，甚至任何相关文章的链接，将不胜感激。

17 architecture  web-applications  enterprise-architecture  angular2  modularization 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 我目前正在评估一个潜在的新项目，该项目涉及为典型的客户信息（用户名，密码，姓氏和姓氏，电子邮件，地址，telfnr等）创建数据库。此时，仅对需求进行了粗略的定义。 预期客户数据库的记录为O（数百万）。为了计算数据库大小和评估潜在的数据库选项和体系结构的一些背景数据，我正在寻找此类记录的实际标准。特别是，每个字段的标准大小（名字，姓氏，地址等）或简单客户记录的平均平均值都是很好的信息。 在拥有如此众多的电子商务网站的情况下，应该有某种可以重复使用的典型配置，并且可以避免重新发明轮子。 有任何想法吗？ ----编辑---- 答案似乎是要采用标准的客户记录而不是设计自己的记录。我想强调的是，这个问题的重点是为客户对象的字段大小确定参考，并避免自己搞清楚（我在原始文本中强调了这一部分，现在以粗体显示）。

17 database  database-design  enterprise-architecture 

对门户空间的幻灭 我看到许多令人困扰的大型企业客户，他们对其企业Portal的经验感到失望，尤其是WebSphere Portal Server（WPS）空间中的客户。数以百万计的投资已经完成，但是通过聚合和集成协作工具实现个性化内容的承诺从未实现。迁移到WPS 7.x是一个巨大的失败，并取代了迁移，客户想知道他们是否应该完全迁移到其他地方。 门户软件：可怕的选择，但是替代品是什么 那里有大量的门户网站仇恨者，有时门户网站解决方案确实过高了，但是当您谈论大型跨国公司时，如何建议他们构建没有门户网站服务器的全球解决方案？ 门户网站并非总是像Tomcat或JBoss AS那样有趣，但是在集成多个应用程序，管理内容，更新作为单独war文件部署的单个应用程序，管理直至Portlet级别的安全性，证明某种对用户的个性化设置，以及管理大型企业作为其内部和外部网站一部分的数千页的繁重任务，是否有更好的技术？ 收集社区见解和反馈 我一直在努力获取尽可能多的见识。我在TSS上写了一篇有关该问题的文章： 市场上还有哪些门户替代品？ 我还将在CodeRanch上恢复一个线程，以查看是否可以从那个英俊的团队中获得任何见识。 更新了线程，要求替代门户软件Stragetty。大约2012年 我也在寻找twitterati（@potemcam）的一些见识。 与其说是交叉发布，还不如说是一种从社区中真正收集到敏锐洞察力的尝试。如果我能得到扎实的回应和经验，我想将它们汇总到TSS的建议文章中。 在Java空间中，什么是企业门户的正确选择？ 顺便说一句，我也将从其他站点交叉链接到该问题，以便有相同问题的人能够来回弹跳，并查看社区对此主题的看法。

17 java  enterprise-architecture 

在工作中，我们已经开发了将近两年的大型内部应用程序；我最近才刚加入该项目，有些架构使我有些困惑，所以我希望这里的人可以在我问建筑师这些同样的问题之前提供一些建议（这样我可以与他们进行有见地的讨论）。 如果下面的内容过长，我深表歉意，我只想在问我的问题之前，先对系统的外观有一个很好的了解：) 设置系统的方式是，我们有一个主要的Web应用程序（asp.net，AngularJS），该应用程序主要只是聚合来自其他各种服务的数据。因此，基本上，它是AngularJS应用程序的宿主。实际上，有一个MVC控制器引导客户端，然后每个其他控制器都是WebAPI控制器。 这些控制器处理来自客户端的调用，这些控制器始终部署到仅托管Web应用程序的主机上。我们目前有4个这样的盒子。 但是，这些调用最终会路由到另一组WebAPI应用程序（通常是每个业务领域，例如安全性，客户数据，产品数据等）。所有这些WebAPI也会一起部署到专用盒中。我们也有四个这样的盒子。 除了一个例外，我们组织的任何其他部门均未使用这些WebAPI。 最后，这些WebAPI对“后端”服务进行了另一组调用，这些服务通常是遗留在各种ERP系统和数据存储（我们无法控制）之上的传统asmx或wcf服务。 我们应用程序的大多数业务逻辑都在这些WebApi中，例如转换旧数据，对其进行汇总，执行业务规则以及通常的事情类型。 我感到困惑的是，在WebApplication和为其提供服务的WebAPI之间进行这样的分离可能带来什么好处。由于没有其他人在使用它们，因此我看不到任何可伸缩性的好处（即，再放入4个API盒来处理增加的负载是没有意义的，因为API服务器上的负载增加必然意味着Web服务器上的负载增加-因此，Web服务器与Api服务器的比例必须为1：1） 我也看不到必须进行额外的HTTP调用的任何好处浏览器=> HTTP => WebApp => HTTP => WebAPI => HTTP =>后端服务。（我的问题是WebApp和WebAPI之间的HTTP调用） 因此，我目前正在寻求将当前的WebAPI从单独的解决方案迁移到WebApplication解决方案中的单独项目，并在它们之间使用简单的项目引用，并使用一个部署模型。因此，它们最终将成为类库。 在部署方面，这意味着我们将有8个“全栈” Web框，而不是4 + 4。 我看到的新方法的好处是 性能提高，因为Web应用程序和WebAPI服务器之间的序列化/反序列化周期减少了 在Web应用程序和WebApi服务器的传出和传入边界上，根据DTO和映射器可以删除（即无需维护/测试）的大量代码。 具有更好的能力来创建有意义的自动集成测试，因为我可以简单地模拟后端服务并避免中间层HTTP跳转带来的混乱。 所以问题是：我错了吗？我是否错过了将WebApplication和WebAPI框分开的一些基本“魔术”？ 我研究了一些N-Tier架构材料，但似乎找不到任何可以为我们的情况带来具体好处的东西（因为据我所知，可伸缩性不是问题，这是一个内部应用程序，因此WebAPI应用程序的安全性不是问题。） 而且，如果我将系统重组为建议的设置，那么在收益方面我将损失什么？

17 architecture  asp.net  enterprise-architecture  n-tier 

我正在考虑一个项目，我们基于WCF的SOA的迁移部分转移到服务总线模型（可能nServiceBus），并使用一些基本的发布-订阅实现命令查询分离。 我对SOA甚至服务总线模型都不陌生，但我承认直到最近，我的“分离”概念还仅限于常规数据库镜像和复制。尽管如此，我还是被这个想法所吸引，因为它似乎提供了最终一致的系统的所有好处，同时又避免了许多明显的缺点（最明显的是缺乏适当的交易支持）。 我从Udi Dahan那里读了很多关于该主题的书，他基本上是 ESB体系结构的专家（至少在Microsoft世界中是这样），但是他说的一件事确实让我感到困惑： 当我们获得更大的实体并在其上具有更多字段时，我们也将有更多的参与者与这些相同的实体一起工作，并且在任何给定时间某些事物触及它们的某些属性的可能性更高，从而增加了并发冲突的数量。 [...] CQRS的核心要素是重新考虑用户界面的设计，以使我们能够掌握用户的意图，因此，使客户成为首选对象对于用户而言是与指示客户已搬家或已获得客户不同的工作单元。已婚。如上所述，使用类似Excel的UI进行数据更改不会捕获意图。 -Udi Dahan，澄清了CQRS 从引文中描述的角度来看，很难与这种逻辑争论。但这似乎与SOA背道而驰。SOA（实际上是一般的服务）应该处理粗粒度的消息，以便最大程度地减少网络震颤，这还有许多其他好处。 我认识到，当您拥有分布良好，消息队列良好且没有RPC负担的系统时，网络颤抖就不再是问题，但是完全消除该问题似乎并不明智。Udi几乎似乎在说，每个属性更改（即字段更新）都应该是它自己的命令，很难想象一个用户可能像传统上那样经常更新数百或数千个组合的实体和属性。网络服务。 给定良好的高度参数化查询，表值参数或对临时表的批量插入，SQL Server中的一次批处理更新可能花费一秒钟的时间；一次处理所有这些更新很慢，很慢，而且OLTP数据库硬件是所有扩展/扩展中最昂贵的。 有什么办法可以调和这些相互竞争的问题？我是否以错误的方式思考？这个问题在CQS / ESB领域是否有众所周知的解决方案？ 如果不是，那么如何确定命令中粒度的“正确级别”呢？是否有一些“标准”可以用作起点（类似于数据库中的3NF），并且仅在仔细分析表明潜在的显着性能优势时才偏离标准？ 或者，尽管各种专家表达了一些强烈的意见，这可能只是其中的一种吗？

17 architecture  enterprise-architecture  service-bus 

我一直在一个相对复杂的应用程序中，该应用程序具有10多个数据库表（聚合，实体/值对象）并应用DDD。此时，它似乎基本上是DDD-Lite，这意味着有应用程序/域服务，域模型（实体，值对象）和存储库。 我拿起一本书《实现DDD》，他首先提到的是DDD-Lite和Bounded Contexts和Domain Events缺失，这是开始DDD时常见的第一个错误。 目前，我已经尝试通过聚合关系来组织域模型，并使用名称空间进行演示。 我没有看到与将域模型项目划分到单独的有界上下文中有关的好处/缺点（尚未）。也许稍后会变得很明显，但我希望获得有关绑定上下文（以及可能绑定到子域等的一些现实生活）的反馈。

16 architecture  domain-driven-design  enterprise-architecture 

在URL中指定REST API的版本是很普遍的，特别是在路径的开头，例如： POST /api/v1/accounts GET /api/v1/accounts/details 但是，我还没有看到将版本与每个API关联的任何设计。换句话说，我们分别维护每个API的版本。即： POST /api/accounts/v2 GET /api/accounts/details/v3 使用这种方法，当需要中断更改时，我们可以增加特定API的API版本，而无需增加整个API的版本。 使用此样式而不是通用样式有什么弊端？

15 rest  api-design  versioning  enterprise-architecture  engineering 

我认为我对Windows 8消费者应用程序开发的期望有所了解。在WinRT之上创建一个新的基于Metro的UI，通过Marketplace将其部署到您的客户中，每个人都将赢得胜利。似乎很简单。不幸的是，我不从事这项业务。 我为大型企业开发内部业务线应用程序。当前，我们使用诸如WPF和Silverlight之类的.NET技术来创建可通过Web或ClickOnce轻松部署给我们用户的丰富UI。这些应用程序可以轻松支持WinXP和Win7，并且我们的开发人员可以使用XAML，这是一种非常可靠的UI技术。 WPF和Silverlight似乎在这一点上有可疑的期货，因此继续投资于这些股票有点令人担忧。但是Metro UI似乎不适用于企业应用程序，并且WinRT API在企业应用程序需要做的“典型”事情上有很大的局限性。 我应该如何设计当前已部署到WinXP和Win7的基于XAML的应用程序，以便它们在Win8上可支持并可以发展？ 出于这个问题的目的，假设ASP.NET之上的HTML5提供的功能不足以适合我要创建的应用程序。我知道我可以在某些应用程序中使用HTML5，但我试图弄清楚在不够的情况下应该怎么做。 编辑1： 这是对@Emmad Kareem的评论的回应。我同意Silverlight / WPF在短期内（2-5年）是可行的。但是，我们生产的应用程序的使用寿命可能非常长（10-20年以上）。因此，给定技术的长期生存能力是我们关注的问题。另外，我们担心，如果社区认为“ Silverlight / WPF开发”中的技术“过时”，那么找到对它们感兴趣的开发人员将越来越困难。我只是想了解我的选择，睁开眼睛做出决定。

15 architecture  enterprise-architecture  windows-8  forward-compatibility 

我一直在开发将支持许多用户的应用程序。问题是我不知道如何验证客户端/用户。 我正在构建一个http://quickblox.com/之类的应用程序，在该应用程序中我将向用户提供凭据，他们将使用这些凭据来构建N个应用程序，在这些应用程序中，他们无法输入用户名和密码来进行身份验证。 让我们假设它如下。（就像QuickBlox一样） 1.用户在我的网站上创建帐户。 2.用户可以创建N个API密钥和保密凭证。（对于多个应用程序） 3.用户将在其应用程序（Android，iOS，Javascript等）中使用这些凭据与我的REST API进行通信。（REST API具有读写访问权限。） 我的顾虑？ 用户会将其凭据（API密钥和秘密密钥）放入他们构建的应用程序中，如果有人获得了这些密钥并尝试模仿用户该怎么办？（通过反编译APK或直接查看JavaScript代码。 我在某处错了吗？我对构建这种三级用户机制感到困惑。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture