简介

精彩点评

• 

  象棋软件测试

  推荐

  当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时，鲜有组织会真正把这句话当回事儿，甚至很多经验丰富的管理者会认为好的计划是成功的一半，遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中，可能很多管理者已经不会简单满足于“响应”，而是选择主动发起变化了。不确定性管理成了这个时代的主旋律，企业的响应力成了成败的关键。 随着这种趋势的深入，架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义，很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性，保证不会因为某个局部的问题而造成全身瘫痪。 然而架构的健壮性却比较难于定义和测试，以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里，当你询问一位资深工程师架构设计时，往往会得到一张搭积木一样的“架构图”。 图的底层是各种数据存储（从经典的Oracle到大数据标配的Hadoop），图的中间是类似Kafka这样的消息管道和传统的ESB（消息总线），上层则是各种业务应用（包括各种Web应用和移动的APP）。 仿佛这是一个流行的“稳定”架构设计。

• 

  郑吒

  推荐

  抛开一些基础知识的介绍部分，剩余的都是总结思考。想法理解的探讨大部分时候要求理解大致在于一个层面，而理解的过程是会随经验和时间发生变化的。期待下一次的温故。

• 

  ltwonders

  推荐

  从可理解程度上来看，比《领域驱动设计--应对复杂软件之道》那本书更好理解一些，含有一些实战的意味，两本书适合交替着看，互相参透。

• 

  清风徐来

  推荐

  可以的，其实我们都在践行只是不知道所以，像readme，包结构划分，聚合根，值对象等等。思特沃克公司我毕业那年接触，里边的人推广和实践一些前沿的东西真的挺好

• 

  郑同学

  推荐

  从业务出发、面向业务变化是我们现代架构设计成功的关键。架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。

• 

  文标 Billgo

  推荐

  二零二零年读完的第二十四本，对书中讲到的点都特能感同身受，提到的很多建议都在工作中不断提炼，但是可惜在公司中并没有同样对这个感兴趣的同事可以参与讨论，有时候我知道问题的症结跟解决方法但是要往前推的时候并不是那么容易解析清楚，或许还是那句话“道可道，非常道”坑是要躺过才知道怎么爬。在技术方面上，我在架构上都已经买好了演进的种子，在上层把控好这个服务便捷跟把领域边界限定好了，整体就可控了。最后，继续实践技术总结。