问题标签 [architecture]

如果您熟悉“建造一个扔掉”这个短语，那么我们似乎已经做到了；我们正在达到我们在线应用程序版本 1 的限制。是时候清理一下了：

• 重新组织代码和 UI
• 统一 UI 流程
• 添加更多功能
• 为未来而建
• 修改我们的数据库结构以处理上述所有问题

实现这种转变的最佳方式是什么？

我们希望避免将所有用户都扔给一个新系统（一旦完成）......他们会吓坏了，我们无法处理呼叫负载。我们的用户涵盖范围广泛，从技术熟练的用于编写软件的类型到那些不知道 HTML 是什么的用户。

在我们确保这个新设计充分解决了版本 1 的足够问题之后，我们是否应该开始一个新的系统“安装”并逐渐将用户转移到它？

我们是否应该（以某种方式）逐步更改系统的每个模块并进行阶段化？这可能很困难，因为数据库布局会发生变化，导致必须调整“核心代码”和几个周围模块的代码。

拥有一组使用尖端版本的应用程序的受信任、耐心、“beta 测试员”客户是否很常见？（这里的目标是获得反馈并测试新系统上的错误）

还有什么建议吗？第一手经验？

通过 Martin Fowler和Steve McConnell的技术债务

YAGNI（你不需要它）通过维基百科

BDUF（前面的大设计）通过维基百科

更新：为了澄清这个问题，我想我也可以这样陈述并保持我的意思：

“作为一名敏捷实践者，您如何在每次迭代中在“快速和肮脏”（在尝试遵守 YAGNI 时无意冒着技术债务风险）和过度工程（BDUF）之间找到适当的平衡？

为动态逻辑数据库模式提供存储的推荐架构是什么？

澄清一下：如果系统需要为其模式在生产中可能由其用户扩展或更改的模型提供存储，有哪些好的技术、数据库模型或存储引擎可以实现这一点？

几个可能性来说明：

• 通过动态生成的 DML 创建/更改数据库对象
• 创建具有大量稀疏物理列的表并仅使用“覆盖”逻辑模式所需的表
• 创建一个“长而窄”的表，将动态列值存储为行，然后需要对其进行透视以创建一个包含特定实体的所有值的“短而宽”行集
• 使用 BigTable/SimpleDB PropertyBag 类型系统

任何基于现实世界经验的答案将不胜感激

我有一个问题，在这一点上我可能想多了，但这里......

我有 2 类用户和组。用户和组有多对多的关系，我想加入表 group_users 我想要一个 IsAuthorized 属性（因为有些组是私有的——用户需要授权）。

您是否建议为连接表以及用户和组表创建一个类？目前我的课程看起来像这样。

我的映射在两个类中都如下所示（我只在用户映射中显示一个，但它们非常相似）：

我应该为看起来像这样的连接表编写一个类吗？

我真的很希望能够调整组成员身份，我想我正在尝试考虑解决此问题的最佳方法。

我见过以许多不同方式托管的 SaaS 应用程序。跨多个数据库拆分功能和模块是个好主意吗？例如，将 User 表放在一个 DB 上，将功能/应用特定表放在另一个 DB 上，或者将其他常用共享表放在另一个 DB 上？

我们有一个简单的域模型：Contact、TelephoneNumber 和 ContactRepository。联系人是实体，它有一个身份字段。TelephoneNumber 是典型的值对象：没有任何标识，不能与 Contact 实例分开加载。

另一方面，我们有用于操作联系人的 Web 应用程序。第一页是“ContactList”，下一页是“Contact/C0001”，显示联系方式和电话号码列表。

我们必须实施电话号码编辑表格。第一个近似的想法是添加一些可导航的页面，如“ThelephoneNumber/T0001”。

但是 ThelephoneNumber 是 Value Object 类，无法通过这种方式识别其实例。

解决此问题的最佳做法是什么？我们如何识别无状态应用程序中的不可识别对象？

这些软件架构各自在哪些领域发光或失败？

哪些关键要求会促使您选择其中一项？

请假设您有可用的开发人员，他们可以编写良好的面向对象代码以及良好的数据库开发。

另外，请避免圣战 :) 这三种技术各有利弊，我对最适合使用哪种技术感兴趣。

我想请教一些关于构建实时系统的架构或技术方面的建议或经验。在我有一些开发“排队管理系统”的经验之前，我已经通过在操作员更改队列号时向所有操作员发送 TcpServer 和 TcpClient 消息来完成。但我认为这个策略有很多复杂和问题。

谁能指导我一些想法或框架？

我对 TDD 有复杂的感觉。虽然我相信测试，但我对测试驱动我的开发工作的想法有疑问。

当您编写代码以满足为满足您现在的需求的接口编写的一些测试时，您可能会将注意力从构建可维护的代码、简洁的设计和健全的架构转移。

我在驱动而不是测试方面遇到问题。有什么想法吗？

我正在考虑在一个新项目中应用实体框架，因为我喜欢它的 OR/M-API 以及存储/概念模型映射功能（当然还有 Linq 和 Entity SQL）。

但是，如果 EF 实体在两者中都用作数据持有者，如何在 UI 层和业务层之间实现松散耦合。如果我在实体驻留在 UI 中时将实体附加到其 ObjectContext，则 UI 可能会绕过业务层并直接连接到数据库。如果我在将实体从它们的 ObjectContext 传递到 UI 之前将它们从它们的 ObjectContext 中分离出来，则不会有更改跟踪，因此我必须“重放”业务层中的所有更改，以便将它们持久化到数据库中（很难实现，尤其是亲子关系）。虽然我不希望业务层降级为“对象树持久性引擎”，但在某些情况下拥有这种能力会有所帮助。

这当然也适用于其他 OR-mapper，但一些替代产品似乎具有更好的分离/附加机制。