There's a site Database Answers that attempts to provide solutions for common database designs. That's not the same as a complete solution like you are describing, but it is a step in the right direction.
You comment "[o]ne can only construct so many [...] systems before" the commonality becomes obvious. However, those who have constructed enough such systems to spot the commonality then attempt to benefit from it by creating their version of the common system, and then they sell it. It is not (perceived to be) in their interest to give other people who might do the same thing a helping hand.
I completely agree, where is the 'Dummy's guide to inventory IT', the accredited data model for customers, addresses and contact details etc etc. I've found myself re-implementing the same code in so many different places, with subtly different fields and logic but basically the same stuff. A few years back I found a site of pre-cooked data models - a small step in the right direction but not the whole story Universal Data Models (no connection). You'll notice that they haven't had much interest in their product though.
I've also worked in a couple of organisations which were developing their own 'universal' data model as a saleable product. One was in the domain of financial services, and they got to 1500+ DB2 tables, and gave up. Organisations pride themselves on being unique, whereas we (the techs) realise that under the hood most are doing pretty similar stuff - I think it might be too damaging to corporate ego to fess up, and admit they're just the same as everyone else using UniversalCustomer (TM) 1.7. Also that makes these companies ripe for a bit of SAP, Peopleware etc.
As a final thought - there's a lot of low hanging fruit for the entreprenaurs here. A decent set of short books describing common domains. I mean the super simple stuff, persons name, address, telephone etc - with all the little foibles like title in different cultures, and phone number layout handled - now there's a book/wiki a lot of people could use.
In my experience where it falls apart is the Use Cases encompassed by the UI. I in fact have designed and built an inventory system that's been applied across a broad variety of organizations and industries (telecomms, food products, healthcare, electronics manufacturing and distribution, consumer products, apparel, aerospace, many others.) After the first half-dozen, a good data model emerged that has served with little variation (extension, but not variation) for all of them.
But even within an industry, for any number of reasons (nature of the product, volume variations, average order size in and out, accounting requirements, employee motivation, etc. etc.) the way the work is done by real people varies hugely, for good reasons.
Note that the examples above all seem to be about deeper abstraction levels - specifically data models - where we programmers can do it our way, to our benefit. The closer to the user we move, the more our interests need to become secondary to theirs.
Worst-case example: Has anyone else noticed the pattern in employee-scheduling and workhour-reporting systems to show one week per screen, and multi-screen data entry forms?
It approaches reusable design from the data model point of view, as opposed to end user requirements or OO designs. However, I find that to be very useful - once you have a good grasp of the data model, you have a big jump on the requirements and the entities that will eventually be modeled as classes.
It would be unsaleable. The first assertion you inevitably get from anyone distributing an RFQ for a system is: "We aren't like other companies. Our requirements are unique." (And the never really are.)
If you are going to reuse the requirements you might as well reuse the code too. But on a lower level I think what you are looking for would be "requirement patterns", along the lines of "programming patterns".
Now here is a book from Microsoft on the topic, but as with all domain patterns, the idea is that they should organically grow and fit the needs of the domain users and experts. If you want the true source of the idea check out the seminal book on patterns, although it's from Architecture and not programming, surprise surprise :)
There was a huge "Software Reuse" movement back in the '80's and early '90's. There was a sizable industry of people building and tuning catalogs of software components. It was seen by many as the future of software. A good overview is Will Tracz' "Confessions of a Used Software Salesman"; google terms "Brad Cox Software IC", "Martin Griss". As I recall, victory was declared and everyone moved on to other problems.
There are various efforts by governments to try and standardize data models to enable sharing between different agencies, but these have little to no adoption outside of where it's required. In Canada, for example, we have CPSIN.
It would be nice to have a central repository of code patterns, all variety of languages. Then we can both show off our amazing code, make it easier to learn from each other, and would also improve overall code quality by having good examples of providing xyz service/product.
I mean, how many of our coding projects that unique that no one else has ever done it?
My rough guess is that 98% of our work is stuff that has been done by other people in lots of different companies, similar industries, similar functional needs.
I mean this is the kind of thing that stackoverflow should get behind. To not only share and talk about problems, but to learn from each other's code as well.
Near as i can tell, you're talking about a library of application designs. The people disposed to sharing such detailed designs are already doing so - in the form of open specifications or open source. The former tends to attract mostly people and organizations already involved in creating products that implement such specs, or products that inter-operate with systems that do. The latter... well, why bother re-implementing the design when you can just hack the source?
As Mark Harrison notes, there are plenty of companies willing to promote their designs for common business systems. "Buy our system, and just bolt on the functionality necessary for your organization", they'll tell you; "why waste time re-implementing something we've already done?" There's really very little motivation for them to share detailed implementation specs, since they really don't want you re-implementing what they're trying to sell you.
Finally... These things really just aren't that complicated. Or rather, they are... but the complexity is born out of size, out of the myriad combinations of arcane requirements that any given organization might impose upon the system. The real work comes in interpreting these requirements, building them into the base system - and tedious though it may be, it's unavoidable.
发布评论
评论（12）
有，但它们通常由想要向您出售解决方案的供应商运营。 :-/;
There are, but they are usually run by vendors wanting to sell you a solution. :-/;
有一个网站 Database Answers 试图为常见数据库设计提供解决方案。 这与您描述的完整解决方案不同，但这是朝着正确方向迈出的一步。
您评论道“在此之前只能构建这么多系统”，共性变得显而易见。 然而，那些已经构建了足够多的此类系统来发现共性的人，然后尝试通过创建自己的通用系统版本来从中受益，然后将其出售。 向可能做同样事情的其他人伸出援助之手并不（被认为是）符合他们的利益。
There's a site Database Answers that attempts to provide solutions for common database designs. That's not the same as a complete solution like you are describing, but it is a step in the right direction.
You comment "[o]ne can only construct so many [...] systems before" the commonality becomes obvious. However, those who have constructed enough such systems to spot the commonality then attempt to benefit from it by creating their version of the common system, and then they sell it. It is not (perceived to be) in their interest to give other people who might do the same thing a helping hand.
我完全同意，“库存 IT 傻瓜指南”、经认可的客户数据模型、地址和联系方式等在哪里。我发现自己在很多不同的地方重新实现了相同的代码，并且字段略有不同和逻辑，但基本上是相同的东西。 几年前，我发现了一个预煮数据模型的网站 - 朝着正确方向迈出的一小步，但不是整个故事 通用数据模型（无连接）。 您会注意到他们对自己的产品并没有太大兴趣。
我还曾在几个组织中工作过，这些组织正在开发自己的“通用”数据模型作为可销售的产品。 其中一个是金融服务领域，他们获得了 1500 多个 DB2 表，然后放弃了。 组织以自己的独特性为荣，而我们（技术人员）意识到，大多数组织在幕后都在做非常相似的事情——我认为坦白承认自己和其他人一样，可能会损害企业的自尊心。使用UniversalCustomer (TM) 1.7。 这也使得这些公司具备了使用 SAP、Peopleware 等技术的条件。
最后一个想法是，这里的企业家有很多唾手可得的成果。 一套不错的简短书籍，描述了常见领域。 我的意思是超级简单的东西，人名、地址、电话等 - 以及所有小问题，例如不同文化中的标题，以及处理的电话号码布局 - 现在有一本很多人可以使用的书/维基。
I completely agree, where is the 'Dummy's guide to inventory IT', the accredited data model for customers, addresses and contact details etc etc. I've found myself re-implementing the same code in so many different places, with subtly different fields and logic but basically the same stuff. A few years back I found a site of pre-cooked data models - a small step in the right direction but not the whole story Universal Data Models (no connection). You'll notice that they haven't had much interest in their product though.
I've also worked in a couple of organisations which were developing their own 'universal' data model as a saleable product. One was in the domain of financial services, and they got to 1500+ DB2 tables, and gave up. Organisations pride themselves on being unique, whereas we (the techs) realise that under the hood most are doing pretty similar stuff - I think it might be too damaging to corporate ego to fess up, and admit they're just the same as everyone else using UniversalCustomer (TM) 1.7. Also that makes these companies ripe for a bit of SAP, Peopleware etc.
As a final thought - there's a lot of low hanging fruit for the entreprenaurs here. A decent set of short books describing common domains. I mean the super simple stuff, persons name, address, telephone etc - with all the little foibles like title in different cultures, and phone number layout handled - now there's a book/wiki a lot of people could use.
根据我的经验，它崩溃的地方是 UI 包含的用例。 事实上，我设计并构建了一个库存系统，该系统已应用于各种组织和行业（电信、食品、医疗保健、电子制造和分销、消费品、服装、航空航天等）。十几个，一个好的数据模型出现了，它对所有这些模型都几乎没有变化（扩展，但不是变化）。
但即使在一个行业内，由于多种原因（产品的性质、数量变化、进出的平均订单大小、会计要求、员工动机等），实际人员完成工作的方式也有很大差异，有充分的理由。
请注意，上面的示例似乎都是关于更深层次的抽象级别（特别是数据模型），我们程序员可以按照自己的方式进行操作，这对我们有利。 我们离用户越近，我们的利益就越需要变得次要于他们的利益。
最坏的情况示例：是否有其他人注意到员工计划和工作时间报告系统中每个屏幕显示一周的模式以及多屏幕数据输入表单？
In my experience where it falls apart is the Use Cases encompassed by the UI. I in fact have designed and built an inventory system that's been applied across a broad variety of organizations and industries (telecomms, food products, healthcare, electronics manufacturing and distribution, consumer products, apparel, aerospace, many others.) After the first half-dozen, a good data model emerged that has served with little variation (extension, but not variation) for all of them.
But even within an industry, for any number of reasons (nature of the product, volume variations, average order size in and out, accounting requirements, employee motivation, etc. etc.) the way the work is done by real people varies hugely, for good reasons.
Note that the examples above all seem to be about deeper abstraction levels - specifically data models - where we programmers can do it our way, to our benefit. The closer to the user we move, the more our interests need to become secondary to theirs.
Worst-case example: Has anyone else noticed the pattern in employee-scheduling and workhour-reporting systems to show one week per screen, and multi-screen data entry forms?
查看 Len Silverston 编写的数据模型资源书籍：
http://www.amazon.com /Data-Model-Resource-Book-Vol/dp/0471380237/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1232336996&sr=8-1
从数据模型角度接近可重用设计视图，而不是最终用户需求或 OO 设计。 然而，我发现这非常有用 - 一旦您很好地掌握了数据模型，您就会在需求和最终将建模为类的实体上取得很大的进步。
Check out the Data Model Resource Book by Len Silverston:
http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1232336996&sr=8-1
It approaches reusable design from the data model point of view, as opposed to end user requirements or OO designs. However, I find that to be very useful - once you have a good grasp of the data model, you have a big jump on the requirements and the entities that will eventually be modeled as classes.
那就卖不出去了。 任何分发系统询价的人不可避免地会得到的第一个断言是：“我们与其他公司不同。我们的要求是独一无二的。” （而且从来没有真正存在过。）
It would be unsaleable. The first assertion you inevitably get from anyone distributing an RFQ for a system is: "We aren't like other companies. Our requirements are unique." (And the never really are.)
如果您要重用需求，您也可以重用代码。 但在较低的层面上，我认为您正在寻找的是“需求模式”，类似于“编程模式”。
现在这是一本来自 Microsoft 的关于该主题的书，但是与所有领域模式一样，我们的想法是它们应该有机增长并满足领域用户和专家的需求。 如果您想了解该想法的真正来源，请查看关于模式的开创性书籍，尽管它来自架构而不是编程，令人惊讶:)
If you are going to reuse the requirements you might as well reuse the code too. But on a lower level I think what you are looking for would be "requirement patterns", along the lines of "programming patterns".
Now here is a book from Microsoft on the topic, but as with all domain patterns, the idea is that they should organically grow and fit the needs of the domain users and experts. If you want the true source of the idea check out the seminal book on patterns, although it's from Architecture and not programming, surprise surprise :)
早在 80 年代和 90 年代初就有一场巨大的“软件重用”运动。 有相当大的行业致力于构建和调整软件组件目录。 许多人将其视为软件的未来。 Will Tracz 的《二手软件推销员的自白》是一个很好的概述； 谷歌术语“Brad Cox Software IC”、“Martin Griss”。 我记得，胜利宣告了，每个人都转向其他问题。
我看到 Brad Cox 的《规划软件工业革命》已上线：
http://www.virtualschool.edu/cox/pub/PSIR/
There was a huge "Software Reuse" movement back in the '80's and early '90's. There was a sizable industry of people building and tuning catalogs of software components. It was seen by many as the future of software. A good overview is Will Tracz' "Confessions of a Used Software Salesman"; google terms "Brad Cox Software IC", "Martin Griss". As I recall, victory was declared and everyone moved on to other problems.
I see that Brad Cox's "Planning the Software Industrial Revolution" is Online:
http://www.virtualschool.edu/cox/pub/PSIR/
各国政府做出了各种努力来尝试标准化数据模型，以实现不同机构之间的共享，但除了需要的地方外，这些努力几乎没有被采用。 例如，在加拿大，我们有 CPSIN。
There are various efforts by governments to try and standardize data models to enable sharing between different agencies, but these have little to no adoption outside of where it's required. In Canada, for example, we have CPSIN.
您可能想查看 Martin Fowler 的 企业应用程序架构模式 - 虽然不是规格，这似乎与您所追求的东西有关。
免责声明：我自己没有读过它，我只知道它的存在。
You might want to check out Martin Fowler's Patterns of Enterprise Application Architecture - while not specs, it seems to be about the sort of things you are after.
Disclaimer: I haven't read it myself, I only know of its existence.
如果有一个包含各种语言的代码模式的中央存储库，那就太好了。 然后我们都可以展示我们令人惊叹的代码，使彼此更容易学习，并且还可以通过提供 xyz 服务/产品的良好示例来提高整体代码质量。
我的意思是，我们有多少编码项目是独一无二的，没有人做过？
我粗略地猜测，我们 98% 的工作都是由许多不同公司、类似行业、类似功能需求的其他人完成的。
我的意思是这是 stackoverflow 应该支持的事情。 不仅要分享和讨论问题，还要从彼此的代码中学习。
It would be nice to have a central repository of code patterns, all variety of languages. Then we can both show off our amazing code, make it easier to learn from each other, and would also improve overall code quality by having good examples of providing xyz service/product.
I mean, how many of our coding projects that unique that no one else has ever done it?
My rough guess is that 98% of our work is stuff that has been done by other people in lots of different companies, similar industries, similar functional needs.
I mean this is the kind of thing that stackoverflow should get behind. To not only share and talk about problems, but to learn from each other's code as well.
谁会创造这样的东西？ 谁会使用它？
据我所知，您正在谈论一个应用程序设计库。 愿意分享此类详细设计的人们已经以开放规范或开源的形式这样做了。 前者往往吸引大多数已经参与创建实现此类规范的产品或与实现此类规范的系统互操作的产品的人员和组织。 后者......好吧，当你可以破解源代码时，为什么要费心重新实现设计呢？
作为 标记Harrison 指出，有很多公司愿意推广他们针对通用业务系统的设计。 他们会告诉您：“购买我们的系统，然后安装您的组织所需的功能”； “为什么要浪费时间重新实施我们已经做过的事情呢？” 他们确实没有动力分享详细的实施规范，因为他们真的不希望您重新实施他们试图向您推销的东西。
最后……这些事情其实并没有那么复杂。 或者更确切地说，它们是......但复杂性源于规模，源于任何给定组织可能对系统强加的神秘要求的无数组合。 真正的工作在于解释这些要求，将它们构建到基本系统中——尽管这可能很乏味，但这是不可避免的。
Who would create such a thing? Who would use it?
Near as i can tell, you're talking about a library of application designs. The people disposed to sharing such detailed designs are already doing so - in the form of open specifications or open source. The former tends to attract mostly people and organizations already involved in creating products that implement such specs, or products that inter-operate with systems that do. The latter... well, why bother re-implementing the design when you can just hack the source?
As Mark Harrison notes, there are plenty of companies willing to promote their designs for common business systems. "Buy our system, and just bolt on the functionality necessary for your organization", they'll tell you; "why waste time re-implementing something we've already done?" There's really very little motivation for them to share detailed implementation specs, since they really don't want you re-implementing what they're trying to sell you.
Finally... These things really just aren't that complicated. Or rather, they are... but the complexity is born out of size, out of the myriad combinations of arcane requirements that any given organization might impose upon the system. The real work comes in interpreting these requirements, building them into the base system - and tedious though it may be, it's unavoidable.