只听本周的podcast，并认为把你的一些经验归为一类是很好的，你已经看到设计的“架构”方面比它应该支配的东西更多。
Java在这方面经常受到不好的压力，并且由于Java EE的复杂性增加而越来越糟糕。在2004年之后，我对Java时间图的经历显着下降，所以我觉得没有资格发表评论。
我最近的经历是建筑师拼命想要在一组（关系）数据库表（恰好是Oracle）中准确地表示对象模型。结果是一个数据库模式，如果没有先加入一堆表（在物化视图中），就无法有效地进行查询。
答案 0 :(得分：12)
哦，是的！
在我上一份工作中，在一个非常大的项目上工作，我们有一个架构团队，它将我们使用的整个框架落实到位。他们设计了一个自定义ORM（大约2000，Hibernate不像今天这样普遍存在）和基于Swing的自定义RCP框架。
ORM并不是那么糟糕。他们只是过分关注循环依赖，所以在某些情况下我们有一段非常糟糕的时间来表达我们的域模型，因为业务确实需要循环依赖（业务对象可以在不同的管理单元之间双向流动）。
Swing框架很糟糕。他们试图实现一个组件模型，看起来有点像分层控制器。它在纸面上看起来非常好：你可以拥有可以重复使用的组件。模型，视图和控制器分开。但实际上，框架没有提供足够的灵活性，因此我们必须保持对JComboBox的引用以通过抽象层获取数据。我们必须为每一小部分UI编写4-5个类。在某些情况下，在表单上添加复选框需要数天时间。调试非常糟糕，因为每个简单的操作流程都要经过15-20个类。令人惊讶的是，表演还不错。
最糟糕的是，每个Swing组件都包含在一个抽象层中“以防我们想要更改UI工具包”！
答案 1 :(得分：7)
答案 2 :(得分：7)
我一直认为This Hello World implementation也很好。
答案 3 :(得分：6)
在我过去五年工作的每个地方！
我的官方职称在过去的六年中都包含了“建筑师”，但是，在一个脾气暴躁的日子里，我更像一个反建筑师，在不那么脾气暴躁的日子里，我是一个“极简主义建筑师”。
如果组件，框架或功能没有一个很好的明确和明显的理由，那么我放弃它！
在我被推翻的情况下，额外的无懈可击的建筑特征一直是最大的问题区域。
答案 4 :(得分：5)
我工作的公司生产一个具有SQL Server后端数据库的应用程序。其中一个主要表格需要加入自己六次才能获得任何有意义的数据！
答案 5 :(得分：5)
答案 6 :(得分：3)
我的一位朋友在一个大型数据库上工作，其中所有必须从自定义类“任何”下载
/颤动
答案 7 :(得分：2)
如果你还没有读过Joel关于建筑宇航员的文章（Live Mesh one），我推荐它 - 这是关于这个主题的好读物。
答案 8 :(得分：0)
我最喜欢的是“自动架构”。基本上只是一套规则，如果你遵循架构正确地落实到位.....显然。
所以这会导致每个对象都有一个接口，无论是否需要抽象和工厂（没有新的（）！）对于每个单一的服务...... 叹息。
答案 9 :(得分：0)
没有
架构不应该从属于要求吗？
答案 10 :(得分：0)
我的宠儿是“架构师”，他们不理解关系概念，并且当数据库以基于集合的方式表现更好并且应该被设计为以这种方式使用时，尝试以对象方式工作。 （数据库不应该由面向对象的程序员转向架构师设计，它们应该由数据库专家设计）并且建筑师认为将多个事物放在一个主基表（过度概括）中然后最终得到100以上更“优雅”该表的外键以及引用它的每个查询和主要的性能噩梦（以及删除记录的荒谬过程）。