sorra
2013-12-26 11:39
取代OSGi可以。不过这个作者说“对象是地狱”“设计模式是失败的”,就变成兜售假药的性质了。因为微服务解决的压根就是另一个问题。

如果服务无状态,那做成一个库就够了。

如果服务有状态,那么事情绝不简单,比如不同用户的并发冲突、需求冲突怎么处理。(MQ仍显naive)

微服务作为模块化方案/异构系统的解耦方案,当然还是有价值的。

banq
2013-12-26 16:12
2013-12-26 11:39 "@sorra"的内容
这个作者说“对象是地狱”“设计模式是失败的” ...

是有些极端,但是还是有一些道理在里面。比如对象的继承是坏的,可以使用组合+依赖。

比如我们分析设计时,原来是首先找出实体为主,后来发现实际应该是首先找出找出聚合,然后又发现首先划分聚合所在的上下文(场景)更重要,到现在,我们都明白了分析设计首先是应该找出分界的上下文,但是这个界限也不是一下子能划出来的,因此我们发现,因为我们人类对动词比较敏感,正如学校刚毕业初学者编程序,开始总是从一个过程函数开始,然后才用到数据结构,算法+数据结构,算法在前面,算法是一个函数或动词。

那么现在我们就是从事件开始,因为事件可以从用例功能里面直接映射出来,有了事件,我们能划分上下文边界,正如我们从流程开始设计,才会发现流程中涉及到哪些实体一样。建模风暴这个PPT也谈了这个问题,先是领域事件风暴,然后才是模型风暴,动词在名词之前,而不是以前宣扬的名词模型在动词之前。

另外javascript的设计模式因为是面向函数风格的,类似GoF设计模式的观察者模式,偏重行为模式,而不是过去我们强调的偏向静态的结构性模式。

其实两者有时不矛盾,比如我们发现了结构性的静止的聚合对象,聚合根实体通过领域事件这个行为与外界交互,微服务是交互的发生地,也就是上下文(场景),如下图:

[该贴被banq于2013-12-26 16:14修改过]

sorra
2013-12-26 21:22
话说回来,其实就是新一代的SOA吧 :) 更强调异步

猜你喜欢