架构的演化和不断新兴的设计

原文 http://www.jdon.com/jivejdon/thread/39232

 

Evolutionary architecture and emergent design: Leveraging reusable code, Part 1

这是IBM的一篇文章，一旦你确认了惯用的模式，下一步你就进入收获期，理解设计和代码之间关系，能够发现可重用复用的代码，这篇文章阐述了代码与设计的关系，指出重要是用一个可表达有表现力的语言，然后重新不断思考抽象，挖掘潜在价值。

文章指出两个惯用模式：
1.技术模式，这些模式强调事务 安全和其他底层技术元素。
2.领域模式，这些包括解决业务应用的通用方案。

文章认为：设计就是代码。从表现力和抽象风格来谈论两者关系。完整的代码是设计工作的目标和结果。

理解这个点就不能理解为什么一些开发失败。比如MDA模型驱动架构中，试图直接从UML产生代码，这是失败的，因为UML语言不够表现力，不够丰富，不能表达细微差别。

要认识到设计是最昂贵的活动(banq:有些公司开发图形化的拖曳或快速开发软件方式，从方向上应该迟早会失败的，如果你能通过开发专门工具来解决这个最昂贵的活动，那么你就是上帝了)。

当 然并不是反对你用UML，一旦代码出来后，你就要明白你进入了新的设计阶段，你就要迁移到这个阶段，这个阶段可读性设计是关键(banq:有些图形化开发 工具开发或生成出来的代码几乎不能看，二次开发还需要通过开发工具去修改代码，不能直接阅读代码，这个方向也大大出错了，不过因为中国人不懂英语，所以中 国软件公司总是试图阻止程序员直接读英文程序代码，而是搞图形化界面，结果越搞越复杂)。

而让代码变得可读，就要使用一些惯用的模式，这样就越容易修改维护拓展，凡是知道这些惯用模式的程序员都能读懂你的代码。(当然这个要求对程序员要高，不但要懂Java语言，还要懂模式)

banq总结：整篇文章虽然没有提DDD ，但是和DDD 或MDD领域驱动设计开发思想是一致的。

 

文章在语言表达力上使用Java Groovy和Ruby来进行了比较，暗指这些语言在细节表达力上要强于UML或其他图形化表达手段。

下面是一段增加订单的业务操作和技术事务 保证操作混合在一起的代码：

public void addOrderFrom(ShoppingCart cart, String userName, Order order) throws SQLException { setupDataInfrastructure();//底层技术 try { add(order, userKeyBasedOn(userName)); //业务操作 addLineItemsFrom(cart, order.getOrderKey()); //业务操作 completeTransaction(); //底层技术事务 } catch (SQLException sqlx) { rollbackTransaction(); throw sqlx; } finally { cleanUp(); } }

很显然，这段代码违背职责单一原则，我们需要对其分离，分离后可再组合应用。使用command模式：

public void wrapInTransaction(Command c) { setupDataInfrastructure(); try { c.execute(); completeTransaction(); } catch (RuntimeException ex) { rollbackTransaction(); throw ex; } finally { cleanUp(); } } public void addOrderFrom(final ShoppingCart cart, final String userName, final Order order) throws SQLException { wrapInTransaction(new Command() { public void execute() { add(order, userKeyBasedOn(userName)); addLineItemsFrom(cart, order.getOrderKey()); } }); }

熟悉Spring+hibernate可以知道，其HibernateTemplate中就是如此实现的。

如果使用Groovy来实现，则会更加具备可读性：

public class OrderDbClosure { def wrapInTransaction(command) { setupDataInfrastructure() try { command() //关键一句 直接运行方法体内代码 completeTransaction() } catch (RuntimeException ex) { rollbackTransaction() throw ex } finally { cleanUp() } } def addOrderFrom(cart, userName, order) { wrapInTransaction { add order, userKeyBasedOn(userName) addLineItemsFrom cart, order.getOrderKey() } } }

由于Groovy语言内置了command模式，所以这里实现起来更加简单直接。

使用ruby实现：

def wrap_in_transaction setup_data_infrastructure begin yield //关键一句 complete_transaction rescue rollback_transaction throw ensure cleanup end end def add_order_from wrap_in_transaction do add order, user_key_based_on(user_name) add_line_items_from cart, order.order_key end end

通过Java以及Java的框架 以及groovy与Ruby比较，展现了语言表达力的魅力，这里体现了模式和语言的关系：如果你为汇编语言找一套惯用的模式是非常困难的，因为语言本身增加了很多不透明因素让你无法看到真正的设计。

由于设计就是代码，代码就是设计，你必须选择最能表达你设计的语言，凭借语言的表现力可以跟容易看到你惯用的模式，也就更容易看到你的设计。


文章认为设计或编码是一项精益活动，精益活动有一个原则：你等待时间越长，你就越有机会寻找到合适的设计。

个人观点：个人体会，不愿意做项目期限很紧的软件，愿意一直精益做好一个软件，比如JiveJdon ；有新项目时，也不是急于立即下手，而是让自己等待。越长时间进行设计决定，你就拥有越多的设计语境，对设计的场景背景就越多理解，就能越多寻找到合适的设计。

当你在一个语言上工作很久，会陷入一种具体战术性细节，而忽视抽象战略思想，当你拥有一把锤子，每个问题看起来都是钉子，每个问题都可以使用你熟悉的语言来抽象解决。

如 果你熟悉java语言，再使用面向函数语言如scala等，你的思维方式就会不一样，你就不会再用你熟悉的锤子从一个角度解决问题，而是更换了另外一个角 度，比如Java中数据结构缺省是可变的，这在一个多线程环境中是危险的，你可以使用很多代码和模式在Java中实现不可变；但是Scala这些语言数据 结构缺省是不可变的，那么在多线程环境中就显然更加干净。

OOPSLA 2006曾经提出反对象概念："Collaborative Diffusion: Programming Antiobjects" , 引入一个叫反对象antiobject, 它也是一个对象，但是它是我们通常认为应该是什么样的反面。这实际是用来扩展我们的思维的一种方法，否定之否定，从另外一个角度重新思考需求，重新思考问 题。