我参与了几次敏捷转换。我所工作的每家公司都提出了同样的问题：我们如何将当前的软件划分为团队，以及我们如何使这些团队与我们的业务目标保持一致？在本报告中，我将.

本文是Google产品技术经理 .

“不要追求完美的代码;争取完美的界限” - DDD的模式，原则和实践。 评：DDD有界 .

这是 mathiasver.

将一小部分事件标记为公共事件，默认情况下保持其他事件为私有。(有界 .

它也称为战略建模，它是DDD的支柱，其主要目标是与整个项目团队（领域专家和技术团队）一起定义有界 .

事件风暴是软件系统的快速设计技术，涉及技术人员和领域专家/业务分析师。它最适合领域驱动设计环境，并倾向于/准备事件溯源和CQRS。该技术最初由Alberto.

模块化的三大优点是什么？如何使用Strategic DDD实现这些优势？  演讲PPT点击标题见原文。下面是意译如下： .

感觉现在是微服务炒作周期的高峰期，看到一篇博客文章“如何将我的巨石迁移到150个服务”。现在我经常听到更多的反击：“我不讨厌我的巨石，我只关心事情保持高效”.

在这个行业中，这是一个广为流传的笑话。无论你问顾问什么问题，答案都是： 这取决于... .

本文作者Alvaro Videla，他是FaunaDB的核心开发人员，在瑞士的家中工作，他还是RabbitMQ的核心开发人员，也是构建德国最大约会网站之一的.

Eric Evans：主题演讲（“上下文中的语言”）： 从基础知识开始（单词在 .

“ 不要重复自己 DRY”，每个开发者都在他职业生涯的早期就学会了这个口头禅。 对这个原则的共同理解是你不应该复制你的代码。就那么简单。 不要复.

复制比错误的抽象便宜得多（代价小成本低），宁可重复而不选择错误的抽象。 让人们意识到“错误的抽象”这个问题是很难： 程序员A看.

微服务是通过否定单体巨石monolithic而诞生的，单体巨石意思是铁板一块，高度耦合在一起，如同搅拌在一起的意大利面，或者说拌面，代码之间纠缠不清，修改维护难度很.

你的微服务是否太小？或者太紧密耦合？本设计指南可以提供帮助。 设计微服务往往更像是一门艺术而不是科学。本文提出五个建议：<.

在这篇文章中，作者讨论了他最近学到的关于从不同的角度识别微服务边界的一个教训。 微服务架构是当今的热门话题。 尽管它的复.

Cribbb是一个使用DDD聚合根和领域事件Domain Events概念开发的PHP开源通知框架： .

Richard Clayton分享了自己在微服务实践中的失败经历，避免更多人犯同样的错误。这些问题主要有以下几点： .

点击标题 [该贴被brighthas于2014-06-24 15:27修改过].