DDD诊所——异步事件综合征
“DDD诊所”是Thoughtworks DDD社区的一项活动,通过对同事们在实施DDD过程中遇到的问题进行分析和解答,共同提高开发水平。我们将其中一些典型案例整理成文供大家参考。之后也会考虑在适当的时候将这一形式对外部开放。
技术链接、资讯与社区分享流
技术圈正在讨论的分享链接。
“DDD诊所”是Thoughtworks DDD社区的一项活动,通过对同事们在实施DDD过程中遇到的问题进行分析和解答,共同提高开发水平。我们将其中一些典型案例整理成文供大家参考。之后也会考虑在适当的时候将这一形式对外部开放。
好的数据质量,经过数据分析、挖掘、机器学习等手段,可以更好地辅助业务决策、帮助企业降本增效;差的数据质量,从数据中获得的价值有限,甚至会误导做出错误的业务决策,从而给企业带来灾难性的后果。
很多新手在刚入门原型设计时,总会花费很多精力在工具的选择和打磨上,却忽略了原型设计的核心。等真正上起手来,只能照猫画虎,没有一个完整且系统的思路。因此我想聊一聊我在设计产品原型时的思考过程,希望对新上路的小伙伴们有所帮助。
在Thoughtworks,我们通过对最佳实践(Sensible Default Practices)、能力和度量的持续治理和改进,在保障交付正确的客户价值和减少浪费的基础上,使交付质量更好,速度更快,反馈更及时,从而达到追求工程卓越和形成发展工程师文化的目的,最终产生客户影响力。
基于Cloud Spanner独特的结构,它能确保客户在以较小的用户群和业务量为起点时,不必过多担心在未来数据量和业务量增长后需要对数据库进行迁移或重新编写的问题。
Matthew Skelton和Manuel Pais在他们提出的团队拓扑学中,倡导团队优先的思维方式,以降低团队认知负载为宗旨,避免工作内容(架构、运维等)超出团队的最大认知负载。
在做 DDD 的培训和工作坊时,会遇到来自客户或学员的疑问,有些问题值得我们深入思考。我整理了一些常见的问题,欢迎补充和讨论。结合 DDD 社区最近的讨论成果,这里我先给出一个简单的参考答案。
本文从“团队协作的五大障碍”出发,首先对团队协作过程中遇到的各种问题进行抽象归类,然后分享我们在团队中试过且效果很好的一些敏捷实践,最后展示建设成果,最后展示建设成果。
借此技术雷达峰会之际,InfoQ有幸采访到了Thoughtworks 全球CTO Rebecca Parsons,请她来跟我们聊一聊技术雷达发布这么多年,希望给大家带来什么样的价值?未来有哪些技术趋势值得关注,以及一名技术人应该如何保持技术前瞻性等话题。
大部分客户其实并不在乎你做的什么敏捷,他在乎的其实是你能不能在规定的时间内交付应该交付的软件。你告诉他我们用的是故事点估算,他会告诉你我不懂你们的故事点,你就告诉我这个功能几天做完。
当数据平台逐渐变成每个企业发展所依赖的重要因素,设计出好用的数据可视化平台便是体验设计师的职责,文章会从设计的角度回答三个问题:什么是数据可视化?为什么需要可视化设计?以及该从何处着手设计一个数据可视化平台?
敏捷转型的过程十分复杂,我们有时候需要做培训,有时候需要做团队教辅,有时候需要推动组织变革,有时候需要引导会议,有时候需要做干系人管理等等,在这么多复杂的场景中,是否可以有一个相对简单的模型,让我们可以区别什么时候应该保持什么样的状态,采用相应的技术呢?
金字塔建议底层单元测试占比应该最多,而顶层UI层测试占比较少,中间层的集成测试居中,整体呈现金字塔结构。这适合比较理想的项目,而实际项目中可能有很多不适合测试金字塔的情形。