模式业务流程业务

我来解释一下为什么要强调模式外无元素，元素外无模式。
>> > 首先既然是元素，就该是基础的构成，稳定的构成，是一种常见的形式。而模式也是一种联系的元素，组合的稳定常见形式，会稳定的出现。如果一个元素会单纯
>> > 的脱离模式存在，就说明其虽然形式稳定，但是其同其他元素的联系不稳定，或者联系的形式和规律还没为我们认识，这种情况下其依然是不稳定的。而如果一个
>> > 模式用到了，非元素，那就说明这个模式还不是基础的联系形式和组合方法，也有认识的死角，还是不稳定的。而我们的基础不应该建立在这些不稳定要素之上。
>> > 同时我并不否认，会存在一些模式，之中存在不稳定的部分，也不否认有些基础构成是不存在于任何模式之中，或许他们还仅仅是我们没有认识到。但是不把他们
>> > 放到基础模型中，并非就不对他们做处理，而是*要区分他们，**做专门的处理*
>> > 。因为就是他们才是不稳定的，其他的都是稳定的----计算机处理稳定的，人处理不稳
>> > 定的。实际上我们经常遇到一些场景，究竟人该做什么，机器该做什么，没有一个划分的标准。我这里就是为这个提供一个依据，用来给设计的时候做权衡。不然
>> > 的话，你到处去算帐，也不知道究竟该算什么，不该算什么。
>> > 这里我还要强调，稳定和不稳定，并非仅仅存在一个层面。元模型所在的层，有稳定不稳定的区分；领域模型也有这个区分；应用层面还有这个区分。他们在各个
>> > 层面互相映衬，互相说明，互相约束。



但是模式外应该无元素，所有的元素都应该有模式使用他们。
>>
>> > > O6Z的意思是否是这些内容之外就是不稳定的呢？ 如果用变化频率和变化剧烈程度来度量"稳定"的话，
>>
>> > 你说的这些元模型和模式也许是最稳定的，其次是领域模型其他的部分，再其次是应用逻辑（业务流程）。业务分析的过程是业务流程----》领域模型----》元模型，在这个过程中可以借鉴以往的经验和中间结果。




 我认为只有在限定的范围内才能尽可能靠近你所说的元模型和模式，模式外无元素的境界是不可能达到的。这等于说你的解空间可以囊括所有给定范围的问题空间。
>>
>> > 有流派尝试那么做，但这样得到的结果是过于抽象的元模型和模式，类似于建模语言了，这种结果对于设计来说用处不大。为什么那样说？我们可以考虑一下，从需求到设计的过程就是不断将泛化的内容特化的过程：例如：人----》客户----》被保险人。
>>
>> > 模型要为这个过程作出贡献，就必须带有特化的内容，供设计复用。特化的内容越多，复用内容就越多，节省的工作量就越大；但同时，特化的内容越多，该内容适用的可能性就越小。这构成一个矛盾：如果要创建一个适用范围很广的模型，那么它的复用内容就越少，节省工作量也少。
>>
>> > 在一个熟练的OO开发工程师的角度，java语言和通用建模语言的描述能力是差不多的----我的意思是：通用建模语言对于设计的帮助就类似于java语言一样----没有直接的作用。
>>
>> > > >       所以模型要有用，一定要限定范围，要在复用内容和适用范围两者间找到一个平衡。按这种理念，我认为DSL是有前途的，MDD是没有前途的。



 这个还不是文字游戏（不过客户的说业务分析和领域建模，以及需求分析，都是文字游戏），因为我这里不仅仅是一个元模型还包括组合元模型的模式。或者说模
>>
>> > 式是元模型的组成形式，而元模型是模式实现的物理操作元件。但是模式外应该无元素，所有的元素都应该有模式使用他们。这还是跟你说的那些东西有差别的。
>> > > >> 也就是因为有了这次，才可以在实施和分析的不同场景下找到平衡点。


呵呵，O6Z兄，说的那么细就有点玩文字游戏了。  领域模型的元模型算不算领域模型的一部分？我觉得算。
>> > > >> > 在DDD中就把领域模型中的元模型部分称为"知识级"模型，而把事务性的模型部分称为"操作级"模型。
>> > > >> > 领域元模型更上位，更本质，往往需要站在全行业的角度去考虑业务。
>>
>> > 按常规而言，越抽象的东西越稳定，但运行效率会越低。例如以元模型属性为条件的查询往往会涉及大量的表联接。所以有些经验建议在分析设计的时候把握其本质，提出并共享元模型知识，但在实际实现的时候，要故意降低抽象级别以满足效率要求。
>> > > >> > 题外话，呵呵。
>>
>> > > >> > 2008/12/18 胖子 <[e-mail]>
>>
>> > 是的。其实往往客户要开发信息系统，就是希望能够将流程A过渡到流程B，并且很可能他们还想保留进一步过渡到流程C，以至于希望更多的优化下去。那么这
>> > > >> > > 个时候你应该如何版呢？
>>
>> > 其实说以流程为中心，也未必是问题。关键还是以什么手段如何分析了。如果你一分析流程的过程，抓住流程的组成要素，也就是元流程，这个时候就是需要你打
>> > > >> > > 破流程而去关注流程下面的东西。
>> > > >> > > 其实就领域模型来说我都觉得可能会不是那么稳定的，我们是否需要去研究组成领域模型的领域模式和领域元模型呢？这个问题我还在思考。
>>
>> > > >> > > On 12月18日, 下午4时01分, "Joseph Tseng" <[e-mail]> wrote:
>> > > >> > > > o6z兄说道的以XX为中心的N中说法，我们也是见多了。
>>
>> > 按XX为中心的说法往往是客户的愿望和需求，如果我们开发时也按照这个说法来处理程序结构就谬误大了！例如客户提的是以业务流程为中心（核心），那是希望我们的程序能够提供围绕业务流程的界面和操作手段，并不是要求我们的程序结构本身要以业务流程为中心。
>>
>> > 我的观念：程序的结构是要求稳，要依赖于稳定的东西。业务流程本身就是企业完成业务的手段，并不是其实质。今年客户企业用流程A完成某业务，明年有可能会用优化的流程B来完成，若不然，还要啥业务流程重组（BPM）呢！所以我说，程序结构要是一业务流程为核心，是一件危险的事情，依赖于不稳定的基础是典型的错误。
>>
>> > 需求分析中什么是稳定的东西？我认为是领域模型。领域模型的逻辑是业务本质，不随手段的变化而变化。举一个例子说，一张保单一定有一个被保险人，这就是领域逻辑。
>> > > >> > > > 又例如，单到付款就是一种流程逻辑（PoEAA里面说的应用逻辑），是映射"支付与确认"这一领域逻辑的。
>> > > >> > > > "支付与确认"是实质，是稳定的，"单到付款"是手段，是不稳定的，是有可能变成其他手段（例如网上支付加递送）。
>>
>> > > >> > > > 2008/12/18 胖子 <[e-mail]>
>>
>> > 哦，从你说的作者来信的意思看，他还是在用瀑布的方法看问题。这个是有害的思想。有机会我要找找原文看看，是不是有必要拿来批驳批驳。
>>
>> > 还有你这里说的话也不是很准备，应该是系统所对应的业务流程是联机事务系统需求的关键线索。这个观点其实是存疑的。首先这个业务流程是事务流程还是信息
>>
>> > 流程或者是管理流程，这三种流程的差异是足够大的，而都属于业务流程，同时系统的偏重性也是不同的，而且看来信息系统发展历史，也存在这三种不同的信息
>>
>> > 系统。在这三种不同的信息系统中，面向的目标也是不一样的，希望达到的效果也是不同的，而且很多时候恰恰是客户希望使用系统达到破坏流程以至于无视流程
>>
>> > 存在的信息传递，以达到流程重组和管理重组的目的。另外一点是很多时候，你的系统是要支持一个并不存在的未来业务流程，或者是支持将现有流程过渡到未来
>> > > >> > > > > 的业务流程。这个时候以流程为核心思考问题就是不合适的。
>>
>> > 本身企业信息系统所面对的情况是十分复杂的，也是多种多样的，不存在一种固定的最优化的形式。今天你也许需要以流程为核心，明天也许就需要以业务点为核