怎样的设计算得上好设计？
就如一百个人眼中有一百个哈姆雷特一样，这个问题多半也不会有标准答案。何况，脱离了具体和细节的业务需求，设计、架构之类的讨论也只剩套路了。
不过，前两天想了想这个问题，还是记录一下吧。
最基础的一点，肯定是功能正确。如果一个设计方案，各种高上大的框架飞来飞去，结果却不能保证功能是对的，那么这方案从根子上就是失败的。
我前两天写了一个小需求的设计，思路是把行计算改成并行计算。而且我用了新的并发stream和ForkJoinPool，感觉突然高上大了起来。结果并发一开，连计算结果都错了。哎，臊了一脸。
反过来的例子就不胜枚举了。
在功能正确之上，是健壮性。包括幂等性、容错性、可用性等。简言之，出现非正常操作时，系统仍然能够处理。
前阵子一个同事设计了一个申请功能。他设计的逻辑是：在申请前，需要校验状态位state!=A；而申请后，这个状态才会被设置为A。结果，当同一笔数据前后两次发起调用时，第一次调用成功，第二次却跑出了异常。这个设计在幂等性上就存在问题，也就是健壮性上存在问题。
容错性稍难点。Java中最基础的做法是try-catch。但是try-catch也有难处。一是异常自身的层次不好；二是异常处理中需要考虑一些关联问题，例如事务的回滚与否、JMS消息是否重试，等等。
可用性比较好理解，简单说就是多点多活。多点多活可以用多线程的思路来设计，但是这个多线程，容易并发、难于同步。
再往上，我认为是扩展性。扩展性不仅仅是系统、技术上的问题。它需要设计师对业务有充分、深入的理解。
例如，技术上，如果我们要把某些功能收在包内，把类、方法的可见性设定为friendly或者protected就行。但是业务上呢？哪些业务功能要收在这个模块内、哪些业务功能可以开放为系统服务？这是需要业务、技术两栖人才能想明白的。
不过，扩展性与这个有什么关系呢？扩展性所考虑的，很多时候就是这类依赖性的开、闭问题。哪些东西可以开放、哪些要关闭；这个功能可以依赖哪些模块、不能依赖哪些模块，这就是依赖性的问题。
TODO linjun 2017-01-03
本文出自 “编程的摩羯男” 博客，请务必保留此出处http://winters1224.blog.51cto.com/3021203/1888737
原文：http://winters1224.blog.51cto.com/3021203/1888737