• 帮助工程团队将函数编程原理应用到高级设计和体系结构与架构的通俗易懂的思想和最佳实践。 关于函数式编程或FP的许多文章都专注于低级编码实践(例如避免副作用)和FP特定模式(例如可怕的monad)。但是,它们不涉及高级设计和体系结构。然而,FP原则可以大规模应用。实际上,从后端的无服务器到前端的Redu icon
  • 领域驱动设计(DDD)是一种软件开发方法:一组用于帮助开发复杂系统的技术,原理和模式。该术语是由Eric Evans在其2004年的著作《域驱动设计:解决软件中心的复杂性》中提出的。 通过无所不在的统一通用语言进行协作 DDD强调域专家和软件开发人员之间的协作。在研讨会期间,双方将反复工作以定义域的 icon
  • 以领域为中心的架构是一种设计现代世界企业应用程序的新方法。 [img] icon
  • 我不会成为程序员的原因,因为我只是对数学问题没有兴趣。除了实用算法以外,我对算法没有任何兴趣。嗯 我的确对领域建模深有感触。我对领域建模深有深厚的感情,我与Eric Evans有类似的领域驱动型设计感觉。 我喜欢与业务领域打交道。我喜欢找到正确的词。我喜欢将其分解,将主要模型分解,并将所有这些东西分 icon
  • 在[url= icon
  • “企业资源计划系统”(ERP系统)之类实际上是一种瑞士军刀软件系统。毫无疑问,它们确实是功能强大的工具,但是在某些情况下,它们可能造成的弊大于利。因此,我想讲一个虚构的故事,该故事显示了组织如何陷入困境。为此,我将尝试使用Nick Tune的全新 icon
  • 大多数人进行SOLID软件设计讨论时都会很快变糟。我们最终为单一职责的“实际含义”而争辩或纠结,由于“开放/关闭”,我们某种程度上又需要抽象基类,并且由于“依赖倒置”,我们还向实体添加了接口。 除了使您的代码“遵循SOLID”之外,还有更多重要的问题需要关注。此外,当您对“原则”非常“虔诚”时,原则 icon
  • 这两种建模方式都是围绕事件展开,但是有区别,事件风暴将会比普通的事件建模在思考层次上更高级,这需要从思维机制讨论: 大脑是一个处理信息的机器,它学习速度很快,可以立即处理数据负载。那么,知识是如何构建的?在何处存储? 人的记忆可以分 icon
  • 在经济高速发展时期,很容易做到技术业务的多样化。 [img] 您有时间和资源分配给所有“额外费用”。 但是,面对经济下滑的情况 icon
  • DDD不是聚合、事件溯源、CQRS、事件风暴等。这些都是工具。它们已被证明在DDD项目中非常有用。但是我们必须小心,不要将演奏乐器与音乐艺术混淆。 对我而言,这是DDD的关键是:与大型系统的复杂性作斗争时,项目团队如何获取领域知识,他们如何构建、开发和普及应用概念模型,以及随着时间的推移,他们如何保 icon
  • 我大约在三年前加入这个行业,当时还只是一个尚未毕业的数学家,后来转为ML实践者。我又花了两年的时间才找到自己的位置,在该职位上,构建软件是我的主要职业。 第一手实战经验非常强大,但是一个人的时间有限。因此,书籍使我有机会学习其他从业者的精通技巧,这些都是经过数千个小时的工作而建立的。就是只能通过阅读 icon
  • 领域概念建模对于我来说是一种很酷的练习,如同初学者区分动词和名词的练习,在副词和介词连用之处发现与获得更丰富的意义。也需要发现这些名词和动词根的约束限制与边界。 目的是要消除隐藏的细微差别,并使它们在设计/代码中显而易见。 阅读书籍,阅读业务领域的文档以帮助理解概念,以便您可以对它们进行更好的建模. icon
  • 很长时间以来,我对公司组织软件开发团队的方式感到失望。 我记得我还是一个年轻的,天真的软件开发人员,我曾假定会存在类似于设计软件架构的结 icon
  • SAP是什么?为何价值$163B? 每年公司在企业资源计划软件(通常称为ERP)上花费$ 41B 。如今,几乎每个大型企业都实施了某种ERP系统。但是,大多数小型企业通常不购买任何现成的ERP系统,而且大多数工程师可能没有看到过它们。 ERP是公司存储其核心运营数据的地方,包括销售预测、采购订单和库 icon
  • 时间和资源是有限的,在开发软件系统时,我们如何花费有限时间并利用有限资源解决最根本、最困难的挑战?在我们可能要做的所有事情中,我们应该做什么,我们应该投资多少质量和严格度? 对于软件工程师来说,自然的趋势是倾向于迎接最有趣的“技术”挑战。尽管并非总是如此,但我可以从自己的亲身经历中确认。 但是,遵循 icon
  • 企业正在迅速采用微服务架构来创建灵活,可扩展的应用程序,这些应用程序可以快速迭代,具有较高的容错能力和较低的停机时间。您如何构建正确的微服务架构? 尽管确切的架构会有所不同,但是有一些最佳实践可以帮助设计有效和最佳的微服务架构。 领域驱动设计 微服务的重点是将统一架构分解为更小,更易管理的部分。必须 icon