不懂得如何做产品，就算懂敏捷又如何？不懂得分布式的架构、操作系统、业务场景，就算能熟背了什么是微服务又如何？也许是新的事物出现的太快，出现的太多，也许是搜索引擎太方便了，使得我们已没时间，更没耐心去探索新的事物背后真正的本质。而只愿意以一任意找到的标准答案，快速、省事的让自己能穿上新事物的外衣；站起来开个会，拍拍手就是敏捷，将产品模块切割就是微服务...更有趣的是，还会以专家的身分批评

架构师应一直铭记在心:微服务正确、适当的边界上下文 (Bounded Context), 绝对是要经由不断的演进与学习而获得的; 没有标准答案, 没有一步到位的。

Docker……终于誏我们真正能实现，将软件的开发变成“软件的组装”。“软件组装工厂，将真正的诞生”。

我们真的已经找到了, 如何以敏捷开发的模式, 做好真正的微服务...只是谈谈鸡汤，开开会，估估没人会真正开心的工作量，站起来拍拍手的敏捷，对任何团队、任何人是ㄧ点帮助都没有的。敏捷应该是（而且已经是证明的）要和软件工程无缝的结合的；使得团队能将市场、行销、研发高效的协作、自主的管理，共同的打造能适应变化、对外部的世界产生最大正面影响的产品 （产品架构）。

微服务的边界 ，粒度是 "决策",而不是个 标准答案。许多人面对微服务时，往往都会纠结着一个问题：微服务太小？太大？其实，会纠结在这个问题上，最根本的原因便是误解了微服务粒度划分这件事的本质；微服务划分本身是 "架构设计"。也就是说微服务划分本身绝不是一个只讲"太大"或 "太小"标准答案的 "是非题"。而是需综合考量以下的因素，所作出的一个 "架构决策"：1. 市场业务的扩

在微服务的架构下, 产品或许会有上百个或上千个微服务。所以, 当这些上百个或上千个微服务, 同时都依赖于某个库 (Library) 时, 则当此共享的库, 即使只是针对某个微服务做些很少量的修改, 也可能会对其他上百个或上千个微服务, 造成不可预期的影响。但在实际的项目中, 产品中的微服务又无法避免的会对某些库 (Library) 产生依赖; 共享某些库 (Library)。所以, 架构师

当我们在做产品时，往往会遇到二种场景：1. 某个特性的场景，无法经由单一的角色或个人分析、思考完整。2. 开发，测试人员过于被动的去接受需求，而不主动思考产品 “应该”要做什么？所以，我在产品级敏捷中，便以 Use Case 2.0为基础，设计了一可视化，协作的 Board。使得各个不同的角色，可经由这样的 Board，而可共同的协作；分析特性的外部直接使用者 (系统, 设

汽车跑的比你快, 你会担忧吗？机器人学习的比你快, 你会需要担忧吗？