刚刚收听了本周的 podcast，并认为将您看到的设计的“架构”方面比应有的更多地主导事物的一些经验汇总在一起会很好。
Java 在这方面经常受到负面报道，并且随着 Java EE 复杂性的增加，负面报道越来越多。在 2004 年之后，我对时间图的 Java 经验急剧下降，所以我觉得没有资格发表评论。
我最近的经历是一位架构师拼命尝试在一组（关系）数据库表（恰好是 Oracle）中准确表示对象模型。结果是一个数据库模式，如果不先预连接一堆表（在物化视图中），就不可能有效地查询。
【问题讨论】：
标签： java database architecture
我工作的公司生产具有 SQL Server 后端数据库的应用程序。其中一个主表需要连接自身六次才能从中获取任何有意义的数据！
【讨论】：
哦，是的！
在我的上一份工作中，从事一个相当大的项目，我们有一个架构团队来部署我们使用的整个框架。他们设计了一个定制的 ORM（大约在 2000 年，Hibernate 不像今天那么普遍）和一个基于 Swing 的定制 RCP 框架。
ORM 并没有那么糟糕。他们只是过度关注循环依赖，所以在某些情况下，我们很难表达我们的领域模型，因为业务确实需要循环依赖（业务对象可以在不同的管理单元之间双向流动）。
Swing 框架简直就是地狱。他们试图实现一个组件模型，看起来有点像分层控制器。它在纸上看起来非常好：您可以拥有可以重复使用的组件。模型、视图和控制器明显分开。但实际上，该框架并没有提供足够的灵活性，所以我们不得不保留对 JComboBox 的引用来通过抽象层获取数据。我们必须为每一小块 UI 编写 4-5 个类。在某些情况下，在表单上添加复选框需要几天时间。调试很糟糕，因为每个简单操作的流程都要经过 15-20 个类。令人惊讶的是，表演还可以。
最糟糕的是，每个 Swing 组件都包装在一个抽象层中，“以防我们想要更改 UI 工具包”！
【讨论】：
如果您还没有阅读 Joel 关于建筑宇航员的文章 (Live Mesh one)，我建议您阅读 - 这是一本关于这个主题的好书。
【讨论】：
过去五年我工作过的每一个地方！
在过去的六年里，我的正式职位一直包含“建筑师”，但是，在脾气暴躁的日子里，我更像是一个反建筑师，在不那么脾气暴躁的日子里，我是一个“极简主义建筑师”。
如果一个组件、框架或功能没有一个很好的明确的理由存在，那么我放弃它！
在我被否决的情况下，多余的建筑功能总是被证明是最大的问题领域。
【讨论】：
【讨论】：
几年前，Joel 的讨论组上出现了一个非常好的比喻。这个故事叫Why I Hate Frameworks。
【讨论】：
我一直认为This Hello World implementation也不错。
【讨论】：
我最喜欢的是“自动架构”。基本上只是一组规则，如果你遵循架构正确就位......显然。
所以这导致每个对象都有一个接口，无论它是否需要抽象和一个工厂（你不需要 new() ！）用于每一个服务...... 叹息。
【讨论】：
没有。
架构不应该服从于需求吗？
【讨论】：
我的一个朋友在大型数据库中工作，其中 所有内容 都必须从自定义类 "Any"
/颤抖
【讨论】：
我最讨厌的是“架构师”，他们不了解关系概念，并试图在数据库以基于集合的方式表现更好并且应该被设计为以这种方式使用时使事情以对象方式工作。 （数据库不应该由面向对象的程序员变成架构师来设计，它们应该由数据库专家设计）以及认为将多个东西放在一个主基表中（过度概括）然后最终得到超过 100 个更“优雅”的架构师该表的外键和引用它的每个查询以及主要的性能噩梦（以及删除记录的荒谬过程）。
【讨论】：