• 微服务是通过否定单体巨石monolithic而诞生的，单体巨石意思是铁板一块，高度耦合在一起，如同搅拌在一起的意大利面，或者说拌面，代码之间纠缠不清，修改维护难度很大，难以增加新功能，而微服务是根据业务领域中自然形成的聚合进行切分，也就是说，微服务不是对单体随意一刀切进行分割，而是根据有界上下文，在
  • DDD关键是发现有界上下文(bounded context)，事件风暴(Event Storming)和领域故事(Domain Story)是两种不同的查找上下文边界方法，他们之间有什么异同？ Eric Evans在他的“领域驱动设计”一书中称他们 icon
  • 为什么领域事件domain events和事件溯源event sourcing不应混淆。领域事件与事件溯源有什么共同之处？共同点是名称中的“事件”一词。但除此之外，在与项目，会议或培训中的建筑师和开发人员交谈时，我经常听到领域事件与事件溯源相关，事件溯源是领域事件的理想来源。 icon
  • 本文作者Alvaro Videla，他是FaunaDB的核心开发人员，在瑞士的家中工作，他还是RabbitMQ的核心开发人员，也是构建德国最大约会网站之一的团队的首席开发人员。他是RabbitMQ in Action的合著者。将现实世界转换为数字抽象需要蒸馏提炼。而且，编程与文学翻译 icon
  • 复制比错误的抽象便宜得多（代价小成本低），宁可重复而不选择错误的抽象。让人们意识到“错误的抽象”这个问题是很难： 程序员A看到重复。 程序员A提取重复并为其命名。这创建了一个新的抽象。它可能是一种新方法，甚至可能是一种新类。 程序员A用新的抽象 icon
  • “ 不要重复自己 DRY”，每个开发者都在他职业生涯的早期就学会了这个口头禅。对这个原则的共同理解是你不应该复制你的代码。就那么简单。不要复制，如果你发现重复就重构。违反此规则的行为将被其他开发人员立即指出为侵犯软件开发最基本的做法之一。 icon
  • 在这个行业中，这是一个广为流传的笑话。无论你问顾问什么问题，答案都是： 这取决于... 这个笑话旨在强调顾问从不直接回答一个简单的问题，因为他们不想承担任何 icon
  • Eric Evans：主题演讲（“上下文中的语言”）：从基础知识开始（单词在上下文中有意义;当我们明确指出这个上下文的边界时，我们最终得到一个有界的上下文），Eric讨论了两个主要的主题：大泥球，以及微服务上下文中有界的上下文。 banq注 icon
  • 今天的企业应用程序无疑是复杂的，需要依靠一些专门技术（持久性，AJAX，Web服务等）来完成他们的工作。作为开发人员，我们倾向于关注这些技术细节，这是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没用，无论它看起来多么漂亮或者如何很好地构建其基础设施。 icon
  • “ 一个微服务应该涵盖一个有界的上下文 ” Vaughn Vernon断言。它引发了与 icon
  • 你的微服务是否太小？或者太紧密耦合？本设计指南可以提供帮助。 设计微服务往往更像是一门艺术而不是科学。本文提出五个建议： 1.它不会与其他服务共享数据库表2.它拥有最少量的数据库表3.它设计为有状 icon
  • 在这篇文章中，作者讨论了他最近学到的关于从不同的角度识别微服务边界的一个教训。 微服务架构是当今的热门话题。 尽管它的复杂性（分布式事务，最终的一致性，操作开销），这些都是不可避免的，但是它提供了许多好处（多边形架构，选择性可扩展性，强模块化，容错，实验 icon
  • 请banq大牛帮助解答一下疑问吧，谢谢最近结合着《Java Modeling in Color with UML(四色原型)中文版》看《实现领域驱动设计》，感觉四色原型里提供的组件并未按照领域驱动设计的思想去做。我把四色原型中的物料资源管理中有好几个组件，我 icon
  • Cribbb是一个使用DDD聚合根和领域事件Domain Events概念开发的PHP开源通知框架：cribbb/cribbb · GitHub icon
  • Richard Clayton分享了自己在微服务实践中的失败经历，避免更多人犯同样的错误。这些问题主要有以下几点： 1.开发人员之间的哲学观点的差异我们团队对微服务分为以下三个派别:a.喜爱微服 icon
  • 这是来自《POJOs In Action》作者和CloudFoundry原创始人Chris Richardson的一篇谈论微服务PPT，结合DDD和事件驱动，比较全面和可落地。大意翻译如下： 以一个在线商店为案 icon
  • Identity用户验证模块 和 论坛模块 是两个上下文 ，通过 identity可以继承各种模块定制个性系统。 论坛独立模块分离完成。 架构如下： Identity用 icon