Bay*_*del 54 domain-driven-design
我目前面临着一个非常不寻常的设计问题,希望比我更聪明的开发人员能够提供一些见解.
没有太具体,我被非营利组织聘用,以协助重建他们的遗产,但非常有价值(在社会价值方面)软件.开发团队不同于我作为软件开发人员时遇到的任何开发团队,由少数开发人员和更多非编程领域专家组成.这种安排的不寻常之处在于领域专家(我们称之为内容创建者),使用自定义工具(其中一些基于prolog专家系统引擎)来开发基于Web的软件组件/表单.
系统使用非常笨拙的回发模型来执行服务器端的逻辑操作并返回新的表单/结果.它很慢,容易出现故障.简单的东西,比如利用现有的工具创建HTML表单是多少更艰巨的比它应该是.随着对更具交互性和高性能体验的需求的增长,软件开发人员越来越多地发现他们必须绕过内容创建者使用的专家系统/可视化工具,并在javascript中手动编写新组件.内容创作者越来越感到他们的双手被束缚,因为他们现在无法贡献新的组件.
我一直在倡导完全放弃以前的模型并采用典型的软件开发过程.如前所述,由于非程序化开发工具已无法满足业务需求,因此该项目自然而然地向此发展.
然而,内容创建者可以做出非常宝贵的贡献,我希望他们能够专注于使用像Cucumber这样的工具正式指定软件的预期行为,而不是参与实现.
我的同事,我非常尊重和怀疑,比我更有知识,认为现有的过程很好,我们只需要建立更好的工具.然而我不禁觉得这种方法存在根本性的缺陷.我还没有找到一个实例,无论是历史还是现代,这种软件开发模式都取得了成功.COBOL的开发理念是允许业务人员/领域专家在不需要程序员的情况下编写应用程序,在我看来,所有这些都是创建一种新的程序员 - COBOL程序员.如果有可能开发出有效的系统,允许非程序员创建非平凡的应用程序,对程序员的需求肯定会低得多吗？我所知道的唯一适合这种模式的框架是SAP的Smart Forms和Microsoft的Dynamix AX--这两个框架都是特定领域的ERP系统.
这两个概念之间的妥协是将某种DSL作为模板语言来实现.我甚至不确定这会成功,因为除了一个例外,所有内容创建者都完全不是技术性的.
我还考虑使用图形/工具箱样式工具构建基于Visual Studio或Net Beans的自定义IDE.
非程序化开发是一个愚蠢的错误吗？这总是会导致一些令人不满意的事情,需要程序员亲自动手吗？
非常感谢您花时间阅读本文,我当然感谢任何反馈.
Dan*_*den 12
你说:
这两个概念之间的妥协是将某种DSL作为模板语言来实现.我甚至不确定这会成功,因为除了一个例外,所有内容创建者都完全不是技术性的.
老实说,这听起来就像我会使用的方法.即使是"非技术"的用户可以成为一个简单的DSL或模板语言,精通(足够),以获得有用的工作完成.
例如,我在科学建模软件方面做了很多工作.许多建模人员虽然在科学方面比在任何形式的工程学中更多,但他们被迫学习一种或多种编程语言,以便以他们可以使用的方式表达他们的想法.哎呀,据我所知,Fortran仍然是获得气象学位所必需的课程,因为目前使用的所有主要天气模型都是用Fortran编写的.
其结果是,有"科学规划",这是大多充满领域专家以相对较少的正规软件工程培训,专业知识,甚至利益某社区.这些人多在家里像Matlab,R,甚至Visual Basic中(因为他们可以用它来脚本应用程序,如Excel和ESRI ArcMap中)语言/平台.最近,我看到Python在这个领域也取得了进展,主要是我认为因为它相对容易学习.
我想我的观点是,我看到这个领域和你的例子之间有很强的相似之处.如果你的领域的专家能够严格地思考自己的问题(这可能不是这样,但你的问题是开放式的,以至于它可能),那么他们肯定能够在适当的领域特定语言表达自己的想法.
我首先要与内容创作者讨论一些关于他们如何表达自己的决定和选择的想法.我的猜测是,他们很乐意编写"代码"(即使你不必称之为代码)来描述他们想要的东西.给他们一个"调试"和一些不错的"IDE"支持应用程序(交互式地探索自己的"代码"变化的结果的工具),我想你就会有一个非常可行的解决方案.
想想电子表格.
电子表格是一个简单的系统,允许非技术用户利用计算机的计算能力.在这样做的过程中,他们开辟了计算机来解决大量任务,这些任务通常需要开发用于解决它们的定制软件.所以,是的,非程序化软件开发是可能的.
另一方面,请查看电子表格.尽管他们的计算能力,你真的不希望作为程序员必须用它们开发软件.最后,许多使编程语言对程序员更好的技术使得它们对于一般人群来说更糟糕.例如,定义函数的能力使程序员的生活变得更加容易,但我认为会使大多数人感到困惑.
此外,尝试使用电子表格过去一定程度的复杂性将是一个真正的痛苦.电子表格在其设计的领域内运行良好.一旦你偏离了太远,它就是不可行的.再一次,它是程序员用来处理复杂性的工具,这将阻止系统广泛使用和足够强大.
我认为对于任何给定的问题领域,您可以开发一个允许专家指定解决方案的系统.开发该系统然后首先解决问题将更加困难.但是,如果您反复遇到专家可以为其开发解决方案的类似问题,那么它可能是值得的.
我认为非开发人员的开发注定要失败.开发人员尝试它时很难.失败率是多少？50%或更高？
我的建议是购买你能找到的最接近的商业产品,或者雇用某人来帮助你开发一个定制的解决方案,同时考虑到非开发人员的维护特性.
作为一名开发人员意味着要立即记住一百万个细节并关注版本控制,部署,测试等细节.大多数不关心这些事情的人很快就会厌倦这种复杂性.
通过各种方式涉及领域专家.但是,不要让他们开发和维护.
如果解决方案做得不好,您可能会使您的组织面临风险.如果这很重要,那就做对了.
我认为任何广泛的非程序员解决方案都不会起作用.编程不仅仅是语言,而是知道如何合理地做事.设计为非程序员友好的东西几乎肯定会包含程序员知道要避免的所有陷阱,即使它用英语或GUI表达.
我认为在这样的情况下需要的是让内容创建者担心制作内容和实际的程序员将其转换为合理的计算机代码.
我使用过两个专为非程序员设计的ERP系统,在这两种情况下,你都可以用它们来解决书中的每一个错误.