做过ERP的进来讨论下

m0_37190407 2016-12-28 12:47:57
我想问问现在外面有多少人做ERP或者其他类型的软件会去使用领域驱动
...全文
657 18 打赏 收藏 转发到动态 举报
写回复
用AI写文章
18 条回复
切换为时间正序
请发表友善的回复…
发表回复
Chen_jiajie1234 2020-03-05
  • 打赏
  • 举报
回复
ERP系统管理的信息面挺广的,主要用于管理生产原料、产品、库存、采购、销售、客户、财务等信息。一般是比较大型的企业才会用到。
wanghui0380 2017-01-03
  • 打赏
  • 举报
回复
其实现在很多“微服务”系统,如果真心考察一下这些“微服务”系统。你就会发现,他符合“领域开发”的理论,一个微服务本身就是一个领域,只是看你怎么划了。 而且领域作为开发指导,很大程度依赖开发团队的核心策划,而不是程序员。因为“领域”本身需要的是很多专业业务知识,而非计算机技术。 如果你更一个丝毫不懂财务知识的团队去讲“财务领域”,他们会集体把你给怼回来,因为计算机书籍告诉他们“3范式”,“性能”,“效率”,而你告诉他们一笔业务会有多个分录,他们天生就不会考虑这个领域,他们会用技术手段去搞(他们会玩分库,分表,触发器,定时任务,优化sql)而不会从领域上解决 同样类似BOM这样的东西,他们一样(他们会玩分库,分表,触发器,定时任务,优化sql),而非单独去搞一个“数据分析规划领域” 我见过一个做所谓“专家系统”的团队,他们的“领域”是,“仓储领域”,“统计报表领域”,“日志领域”,而非“BI领域”
  • 打赏
  • 举报
回复
至于你说的“会不会去使用领域驱动”,其实我一直想尽量回避这类问题。这类问题其实就好像是问“中医是不是骗人的?”,这其实是个伪命题,但是目的也许是好的,但是前提是许多人并不想从中研究什么可操作的东西、而是纠结“彻底黑他,还是假装追随他为大哥而赚点自己的牌面”。 这样我们讨论的层面其实是不一样的。我们充分研究了它,然后才批评它。而有的人是根本学不进去。
  • 打赏
  • 举报
回复
《领取驱动》是一本(或者一系列)著作,可以学习一下。 但是其软件工程性、可操作性并不是很强,比较混沌。这就好比如说古代的医术跟现代的西医的研究方法是不同的,而领域驱动这个流派更多地是从需求、模糊的古代方法来研究软件工程的。如果你把它的东西写成规则你就会发现,你写不出来能具体每天、每小时的可操作的代码,你只能说它的一些概念。 而敏捷的软件开发过程,每天、每小时的东西都可以写成代码,并且自动化地反映进度。而不是概念。
wanghui0380 2017-01-03
  • 打赏
  • 举报
回复
也就是大有大“领域”,小有小“领域” 一个登录,获取权限,增删改查,在某些人的口里也能叫“领域”,那么还有什么不能叫“领域”呢??
wanghui0380 2017-01-03
  • 打赏
  • 举报
回复
道理很简单,“领域”这个词本身就没有明确划分。而写领域分析那本书的人也没有明确划分,大部分号称UML和领域分析的大咖的搞了5,6年唯一成功的领域是那个“ATM机” 我们说,什么是领域本身就看个人本事,你有本事你可以画出“财务领域”,“BOM领域”,“管理领域”,你没本事也能画出博客园粉最喜欢玩滴什么“人员登录领域”,“权限领域”,“数据保存仓储领域” 所以关键是看个人本事,而不是看这个词
m0_37190407 2017-01-03
  • 打赏
  • 举报
回复
引用 10 楼 daixf_csdn 的回复:
[quote=引用 8 楼 m0_37190407 的回复:] [quote=引用 6 楼 daixf_csdn 的回复:] 没实力不要去搞什么领域驱动。我说的这个实力不只是你架构师的实力,而是整个研发团队的实力。 架构师没有这个实力时,设计就会变形,而变形后的设计非常可怕,那就是个资源黑洞,大量的吞噬资源和效率。 如果架构师有这个实力,但程序员没这个实力去对领域驱动理解到位和落实(我相信能有深度理解领域驱动的程序员的比例是很低的),开发也会变形,结果一样,用了领域驱动,带来的反而是灾难。 我的结论就是: 大多数研发团队,都没有能力去实现领域驱动,还是踏踏实实的把自己能做好的做好就行了。 领域驱动么,把它当智力玩具,玩一玩,是可以的,但不要当真了。
我们公司一直在用,但是里面的概念太复杂了,基本上外面进来的人如果没有几个月的培训都很难帮忙做,但是如果理解透了做起来就很简单了[/quote] 领域驱动概念,这也是舶来品。那么号称做ERP的头把交椅的SAP的系统,应该应用了领域驱动了吧,但做起来怎么样呢? 我有幸参与了一下二次开发,我不想再参加第二次。 楼主不妨给我们讲讲你们ERP实现的领域驱动是怎么样的设计理念?[/quote] 我只是个开发人员,看着设计写代码还行,你叫我讲这些概念就比较难了
derekteng 2016-12-30
  • 打赏
  • 举报
回复
领域驱动是软件设计开发管理的概念吧。 ERP只是应用软件的一类。
圣殿骑士18 2016-12-29
  • 打赏
  • 举报
回复
引用 8 楼 m0_37190407 的回复:
[quote=引用 6 楼 daixf_csdn 的回复:] 没实力不要去搞什么领域驱动。我说的这个实力不只是你架构师的实力,而是整个研发团队的实力。 架构师没有这个实力时,设计就会变形,而变形后的设计非常可怕,那就是个资源黑洞,大量的吞噬资源和效率。 如果架构师有这个实力,但程序员没这个实力去对领域驱动理解到位和落实(我相信能有深度理解领域驱动的程序员的比例是很低的),开发也会变形,结果一样,用了领域驱动,带来的反而是灾难。 我的结论就是: 大多数研发团队,都没有能力去实现领域驱动,还是踏踏实实的把自己能做好的做好就行了。 领域驱动么,把它当智力玩具,玩一玩,是可以的,但不要当真了。
我们公司一直在用,但是里面的概念太复杂了,基本上外面进来的人如果没有几个月的培训都很难帮忙做,但是如果理解透了做起来就很简单了[/quote] 领域驱动概念,这也是舶来品。那么号称做ERP的头把交椅的SAP的系统,应该应用了领域驱动了吧,但做起来怎么样呢? 我有幸参与了一下二次开发,我不想再参加第二次。 楼主不妨给我们讲讲你们ERP实现的领域驱动是怎么样的设计理念?
m0_37190407 2016-12-28
  • 打赏
  • 举报
回复
如果你们做一些真正的ERP,如果没有这些概念支撑,系统的可维护性有多高
m0_37190407 2016-12-28
  • 打赏
  • 举报
回复
引用 6 楼 daixf_csdn 的回复:
没实力不要去搞什么领域驱动。我说的这个实力不只是你架构师的实力,而是整个研发团队的实力。 架构师没有这个实力时,设计就会变形,而变形后的设计非常可怕,那就是个资源黑洞,大量的吞噬资源和效率。 如果架构师有这个实力,但程序员没这个实力去对领域驱动理解到位和落实(我相信能有深度理解领域驱动的程序员的比例是很低的),开发也会变形,结果一样,用了领域驱动,带来的反而是灾难。 我的结论就是: 大多数研发团队,都没有能力去实现领域驱动,还是踏踏实实的把自己能做好的做好就行了。 领域驱动么,把它当智力玩具,玩一玩,是可以的,但不要当真了。
我们公司一直在用,但是里面的概念太复杂了,基本上外面进来的人如果没有几个月的培训都很难帮忙做,但是如果理解透了做起来就很简单了
m0_37190407 2016-12-28
  • 打赏
  • 举报
回复
引用 5 楼 sp1234 的回复:
[quote=引用 3 楼 leo2003 的回复:] 领域驱动 什么先进技术? 百度了一下,也没看懂。 本人也写 ERP ,完全不懂 “领域驱动”呀
那些是软件的事情。技术是最低级的(有些人本末倒置地满脑子都是“技术”,最后傻了),如果你问业务,那么跟技术并没有可比性。 ERP是资源计划系统。国内的财务软件、OA软件、人力资源软件等等行业,后来都扯到的ERP的名头上。 简单来说,ERP的核心是规划论、系统工程,在管理科学的各种广泛的应用,用到价值链上下游的每一个环节。当然一些只知道“增删改查”的人也来开发设计 ERP(只要搞定某位政府、部队、大企业的小主管),而且有许多开源的 ERP 系统可以拿来炒,所以这东西实际上很“杂”。 再来说某种软件分析的流派,我并不想多说,我建议你看它的效果、看它产生的实际设计蓝图,不要看它本身玄乎的入门书。[/quote] 我们公司就是做ERP的,做了十多年,一直都在使用领域驱动,但是最近我接触比较多外面做ERP的,但是感觉好像都没有用这个东西,或者所根本不知道领域驱动的存在,我个人觉得,如果一个稍微大型点的ERP系统没有这些设计概念支撑,哪怕最后真的完工了,也很难进行维护,所以今天才会发这个贴找大家探讨下这个问题
圣殿骑士18 2016-12-28
  • 打赏
  • 举报
回复
没实力不要去搞什么领域驱动。我说的这个实力不只是你架构师的实力,而是整个研发团队的实力。 架构师没有这个实力时,设计就会变形,而变形后的设计非常可怕,那就是个资源黑洞,大量的吞噬资源和效率。 如果架构师有这个实力,但程序员没这个实力去对领域驱动理解到位和落实(我相信能有深度理解领域驱动的程序员的比例是很低的),开发也会变形,结果一样,用了领域驱动,带来的反而是灾难。 我的结论就是: 大多数研发团队,都没有能力去实现领域驱动,还是踏踏实实的把自己能做好的做好就行了。 领域驱动么,把它当智力玩具,玩一玩,是可以的,但不要当真了。
  • 打赏
  • 举报
回复
引用 3 楼 leo2003 的回复:
领域驱动 什么先进技术? 百度了一下,也没看懂。 本人也写 ERP ,完全不懂 “领域驱动”呀
那些是软件的事情。技术是最低级的(有些人本末倒置地满脑子都是“技术”,最后傻了),如果你问业务,那么跟技术并没有可比性。 ERP是资源计划系统。国内的财务软件、OA软件、人力资源软件等等行业,后来都扯到的ERP的名头上。 简单来说,ERP的核心是规划论、系统工程,在管理科学的各种广泛的应用,用到价值链上下游的每一个环节。当然一些只知道“增删改查”的人也来开发设计 ERP(只要搞定某位政府、部队、大企业的小主管),而且有许多开源的 ERP 系统可以拿来炒,所以这东西实际上很“杂”。 再来说某种软件分析的流派,我并不想多说,我建议你看它的效果、看它产生的实际设计蓝图,不要看它本身玄乎的入门书。
健者天行 2016-12-28
  • 打赏
  • 举报
回复
能不能简单 通俗地介绍一下 “领域驱动” ??? 有什么先进特性? 有什么优势?
健者天行 2016-12-28
  • 打赏
  • 举报
回复
领域驱动 什么先进技术? 百度了一下,也没看懂。 本人也写 ERP ,完全不懂 “领域驱动”呀
m0_37190407 2016-12-28
  • 打赏
  • 举报
回复
引用 1 楼 hefeng_aspnet 的回复:
领域驱动 每人理解都不同 ERP目前用的应该不多
那么现在外面的ERP都是怎么设计的
csdn_aspnet 2016-12-28
  • 打赏
  • 举报
回复
领域驱动 每人理解都不同 ERP目前用的应该不多
20世纪80年代,连接分离的局域网段的一种简单廉价的方法就是采用网桥,虽然路由器也被用来创建结构及增加功能,但它往往使系统变得复杂和昂贵。网络管理员们过去一直在努力解决如何应用这种新的路由技术来设计最优化的网络,以及选择何种路由方法。另外,一些网桥销售业绩很好的商家没有及时响应对路由器的需求而失去了可观的市场份额。 当前在第二层(L2)交换和第三层(L3)交换的发展过程中出现了与此相类似的现象。从技术的角度来看,L2交换与网桥有着相似的特点,即价格低廉和易于使用。在最近三年中,L2交换市场从零发展为价值数十亿美元。在网络中路由功能仍然是必需的,L3交换承诺能够满足这些需求,并且该方式比过去的路由器更为快捷、简单和廉价。 我们相信业界将会像过去努力推广路由器一样去推广第三层交换,为此网络专业人员将会面临以下四个问题: 1) 争取对已有网络进行升级的批准和资金支持通常比最初建设时要困难得多。 2) 存在几种应用L3交换来设计网络的方法。 3) 厂家采用多种方法来实现L3交换,而通常的规律是:市场上提供的多种选择使买方感到迷惑,结果他们往往没有买到最新的产品。 4) 人们通常会对新技术的引入持怀疑态度,业界已有太多曾经被大肆宣扬的技术最终被市场所淘汰的例子(例如,100VG-AnyLAN和ATM-25)。 只要潜在的买主仍在探索之中,厂家就不可能最后成功。例如,如果网络专业人员不能区分各种L3交换的方法,不设计采用L3交换产品的网络,不针对网络管理进行升级,厂家就不可能向他们出售产品。另外我们也看到,各个厂家往往仅专注于自己的实现方式,而没有意识到他们有必要更广泛地了解所处的环境,包括网络管理员的需求以及竞争对手所提供的实现方式。 本书的目的是扫除在引入新技术特别是第三层交换时人们认识上的一些障碍。我们将指导购买者评估第三层交换是否适合他们的特定情形,我们还将详细介绍这一技术的细节及一些厂家的实现方法及其产品。对于厂家来说,本书将有助于他们更好地理解其潜在的买主在购买和部署第三层交换产品时所面临的问题,以及如何将自己的产品在更广泛的市场中定位。 本书内容覆盖范围 当今社会的特点是“以信息为基础”或者是某些人所说的“以知识为基础”,我们也明显地看到当今经济的发展趋势是一种“全球性”的经济而非区域性的或国家范围内的经济。由于“时间就是金钱”的意识和各种商业压力,我们越来越迫切地要求通信系统能为我们提供对关键信息及时获取的能力。对于许多商业机构和组织来说,其业务和竞争力的核心已经是计算机和网络。从自动化工厂到电子商店,从企业资源规划(ERP)到在线预订,从数字图书馆到个人主页,可靠而高效的网络正日益成为我们工作和生活的基础。“拥有越多,奢望越多”已经变为“拥有越多,需求越多”,没有任何一家商业机构和组织希望他们的计算机网络在下一年度或以后缩小规模。让更有经验的人员操作更强大的计算机以获得更多简单而先进的应用一直是计算机容量、性能和可靠性不断发展的持续动力。关于这方面的内容将在第2、3和8章中更进一步地讨论。 不知您是否在这样的环境中工作过:新技术不是被商业需求所“拉动”,而是被其拥护者所“推动”(有时为了他们自身的原因);公司中产品的开发仅仅是受工程效益的驱动而没有考虑其市场潜力;某人拥有配备最新硬件和软件的计算机不是因为绝对需要而仅仅是因为别人已经拥有。如果是的话,那么您将深刻地领悟到技术的作用(不管是正面的还是反面的)通常是如何被夸大其辞。字处理工具软件没有真正夺去许多秘书的工作,自动柜员机没有消除对传统银行机构的需要,电视和计算机也没有对我们教育大多数学生的方式产生根本性的革命,大多数人只知道使用他们的应用软件的一小部分功能。计算和网络更是在其高承诺和低交付方面受到普遍指责。但还是有一些众所周知的取得巨大成功的典范,如美国医院供应系统、美国航空公司和Frito-Lay公司。本书讨论了与新技术相关的诸多方面(关于第三层交换的深层讨论在第4~6章中给出),您可以发现第2章中列出的一些标准在对新技术进行初步评估时是非常有用的(见表2-1)。 第7章针对Strategic网络公司提供的案例研究给出了几个应用第三层交换产品的网络设计方案。该案例也许与您自己或您客户的环境并不相同,但您将发现第2章中列出的评估新技术适合程度的过程(见表2-1)可用于确定该案例中哪一部分符合您的情形。将这些步骤规范化以及将网络风险承担者牵涉进来有助于减少在事关企业能否成功运作的网络中引进新技术所带来的风险。 最后,第9章进行了综合分析,为要成功部署或销售第三层交换产品必须注意的10个最关键问题给出了我们的建议,并指出其中哪些具有更广泛的通用性。如果可能,其中的某些观点能帮助读者在应用第三层交换技术以及将来应用其他新技术时最大限度地降低风险。 阅读指导 本书主要面向那些正试图升级其机构局域网基础结构的人,读者将在下述几方面受益: ?制定应用于第三层交换以及其他任何新技术的成功评估和部署中的方法和评估标准。 ?有关第三层交换技术的深入解释。 ?关于第三层交换技术针对三个常见网络问题的不同解决方法的建议,这三个问题分别是:优化网络主干、优化服务器以及从FDDI结构移植。 本书对于其任务就是把他们的产品进行市场定位的人员也将非常有用,本书将帮助他们分析客户环境中的机遇和挑战:目前的状况,驱动或阻碍改变的因素,使用何种标准来评估第三层交换技术;此外,本书也能够为他们提供在市场中定位自己的产品时所需的背景知识。 应当说有了注意事项,才算得上一个完整的介绍。计算机和网络技术变化的步伐似乎不会放慢,尽管我们很想知道它是否会一直加速。因此很重要的一点是应当看到,本书所介绍的产品细节乃至关于第三层交换技术的信息从某种意义上说也许只在相对短暂的一段时间内是准确的。技术本身会发展,产品也会改进或被新一代产品所取代。然而我们相信,书中所提供的评估新技术的方法将一直有效,您可以在厂家开始讨论他们“第四层交换”的解决方案时进行尝试。 另外有必要指出的是,我们从来没有试图在本书中覆盖第三层交换的所有解决方案和产品。我们所选择的在市场中居领导地位的主要厂家及一些新兴公司的令人感兴趣的产品也许并不与所有人的选择一致,但我们确实认为所做的选择有相当广泛的代表性。如果您是一个潜在的买主,我们的分析将有助于您评估其他产品。对于我们在书中未做介绍的厂家,从本书中也可以大略地了解到我们认为谁会是您当前主要的竞争对手。 虽然本书介绍的内容是一项特定的技术,但我们并不认为它是一本技术书籍。对于某些人来说,也许我们提供的技术细节比他们想象的更多;而对于另外一些人来说,也许我们介绍的技术细节还不够。我们的目标在于提供如何看待第三层交换以及评估它和其他新技术的框架。这是一项富有挑战性的工作,我们将请您来分享我们在此所奉献的热情和关注。

110,547

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧