话说我的软件架构已经连载三篇了，呵呵～～ 也许这三遍都比较基于概念化，我也觉得这样的评论很中肯，毕竟吧，我还是一名打工者的身份，你懂的。接下来我们说点什么呢？关于软甲架构层面，好吧。今天来点实战性的，不过还是概念级别的。或者也许是方法论吧。实现呢就看自己的造化了，我的理论是写给知音看得，看懂了就鼓励下，觉得不屑一顾的还是收下留情一点。哈哈～～ 人在江湖飘，哪有不挨刀啊。
之前在网络上看到过一则如此搞笑的面试问答，在这里分享与大家：
面试官：什么是J2EE
应聘者：增删改查就是J2EE
忽然一看，觉得是一个笑话，可是你仔细想过没有，他的回答是很等的高度抽象，概括啊。我觉得是大智若愚的一种表现。现在是一个Web盛行的年代，发展到今天，Web已经是一个很成熟的行业了，现在的Web战争已经从PC转移到手机领域了，目前我们讨论的Web还是基于PC的。有点跑题了，回归主题。基于Web开发主要的技术就是J2EE、.Net 、PHP三大阵营吧，其中各有自己擅长的领域，就拿我所熟悉的J2EE吧，现在的J2EE使用最多的场景还是基于三层架构的部署（Http+APP+数据库），说到底还是增删改查啊。哈哈 是不是被绕了一下呢？再说业务定位，J2EE的功能定位主要面向各种业务的，注意这种业务是具体的与人类活动紧密联系的业务，例如网银、电商、政府系统、移动电信业务支撑系统等，相对于更加底层的例如BOSS系统、通信网关等作为C语言更加有优势。好了，上面铺垫了很多，大家只能我表达什么意思了吧。你要是没明白说明是我的责任，我的表述有点混乱了。说到底，业务也是一种流程。这是核心，“流程”二字值得深思，搞IT的很多都是基于计算机系毕业吧。也许大一的时候就学习了程序流程设计吧，回忆回忆，其实呢？这些才是业务的本质。也许程序流程来的太简单了一些，UML建模更加接近我今天要表述的思想。
单独作为一段：业务其实就是流程的一种展现，流程设计其实就是对业务的一种计算机建模。
UML包括各种图，我理解如下，用例图是用来划分程序边界的，看似最简单的一种图，其实包含着最基础最原则的概念。边界的划分。协作图：其实就是对程序的内部的功能切割以及功能边界的定义，也是一种设计模式的体现。状态图是比较重要的，他标志业务流程每个点的走向，时序图是从层次上对设计的一种直白展示。包图与类图是比较细粒度的设计了，没什么讨论的必要了。在结合大学年代我们学习的程序流程图，是否明白点什么了!
所谓的各种业务其实到了计算机层面都是一个一个的流程建模（有限状态下），这是一个思想认知的层次，既然达到这个层面，下面大家都会在思考，如果能设计一套能解析流程的解析引擎，这样就可以利用这个快速组装各种流程，只要给我业务流程图，我就可以快速搭建业务程序模型。开始明白一点了吧。让我一步一步诱导你继续思考下去吧。把所有业务都看作流程才是第一步需要修炼的。接下来开始思考下面的问题，看似很白痴，但是却很实用。
流程的粒度如何去划分呢？流程是定义出来了，解析流程的引擎也设计好了，但是这个每个流程的粒度如何去划分呢？太粗太细都不好，这时业务专家派上用场了，他会从一个业务的高度去描述整个系统的每一个功能环节的流程，架构师拿到这些业务描述，需要做的事情就是进行分析，去揣度流程节点的粒度，那些需要细分，那些需要作为整体，那些组要用子流程去表述。那些流程节点可以复用，那些可以单例运行，那些需要多例实现等等之类的。这靠的就是业务专家与架构师的配合程度了。通常要是能合二为一是最好了，即使架构师同时又是业务专家，这种人太珍稀了，绝对是炙手可热的业内人物，估计价格也不会太低。所以呢 作为企业还是从内被培养自己的这种人才吧。
流程的粒度出来了，但是这些仅仅实现的是协作图，到包图、类图还有一段距离，现在需要考虑的就是时序图以及状态图了。从架构的角度去吧这些模型在打乱，从新分类，从计算机功能再次分类，例如通信模块、DAO模块、MVC模块、 基础支撑模块，这样设计出一种自上而下 没有回路、分层明确的架构图，大家可以参考Spring Security 项目分层设计，那是相当的规范与漂亮，真的是一件艺术品的。到了这一步了，作为架构师的你还没有完成最后的设计，不过也差不多了，按照你的设计定制各种接口，以及流程配置。这些都做好了。剩下的就是开发对接口的实现了。
上述是一种比较规范化的方式，平时我也在与同事交流我的这种思维，他们都说这不就是BPM吗？我承认的确有BPM的影子在里面，但是他不仅仅是BPM这么简单，BPM的设计的领域比较专一，但是我的这个相对于BPM更加的灵活与清晰，作为一个流程可以体现在一个业务节点上的更加细粒度的流程，这个可以采用微积分的思维去看待更加的贴切一些，微积分都知道吧，很神奇的一种思维模式，当年学习球体的体积公式推算，还是很清晰的回忆，当把球体横向切开，主要切的足够薄。则可以忽略球体本身带来的不规范，把每一个切片看作一个圆柱体去计算他的体积，之后在累加。与我目前阐述的这种设计模式很想，只要你喜欢，这个流程引擎可以进行任意粒度的分解，完全不用考虑状态的变化。
今天书写的内容不是很多，但是我觉得大家应该下去多思考思考，基于架构的架构，在此基础上多思考，用自己的语言去设计你的流程解析内核吧，可以基于数据库，也可以基于配置。另外一点我分享一点我的内核架构，我这里把数据库事务处理、sql执行以及page分页都作为单独的节点去设计，流程可以看作是基于配置的AOP的实现。不是吗？什么是AOP呢?自己去翻阅资料吧，这个就不再讨论范围之内。哈哈～～～
有一些开源的框架与此有类似的想法，推荐大家去学习，JBMP ApacheCommons 下的 chain 项目也是类似的，Spring的WebFlow框架也是由此，我是结合上述所有的功能的大集成的一种综合描述。
从无到有，只要自己努力去实践，那么你也会推出属于自己的架构。另外在思考一下，这样的架构师不是觉得很敏捷呢？程序开发完全解耦，流程完全基于配置。其灵活性不言而喻，一开始就是一个清晰的可运行的框架，可以作为持续构建的平台。哇塞 太敏捷了吧～～～～
最近比较忙～ 我也在重构我的内核 大致思想如此！但是我觉得还是不全面有更好的可以回帖一起讨论。白天上班，晚上回家的几个小时 很忙～～