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