今天和朋友聊天的时候，突然想到的。抽象，其实就是放弃细节。
舍弃了细节之后的东西用一个概念性的东西来表征就是抽象了。
舍弃了细节之后的东西用一个概念性的东西来表征就是抽象了。
前些天和朋友谈MDA的时候，讲到业务语言。我就问到业务语言除了对业务实体的元建模，那么具体的业务逻辑能不能表达。最后大家被我引导到了业务语言能表达所有的业务逻辑这个方向上了。其实现在看来，所谓业务语言不过是建立一种针对这个业务的抽象。也就是舍弃了用IT实现技术（源代码等）来表达业务逻辑所包括的一些IT实现相关的细节。很多人怀疑如果业务语言也能表达一些选择判断之类的东西，以充分表达业务逻辑之后，那样的业务语言，也许叫模型是不是和现在的Java写的代码没有什么区别了。那现在看来，问题关键就是现在的实现技术中除了核心的业务逻辑之外，是不是有很多能够抽象掉的细节。
在肯定了需要舍弃一些细节。把固定不变的业务逻辑和交互逻辑提取出来之后。要考虑的就是在这种抽象和实现之间能不能有什么可行的转换办法。如果这种转换需要大量的人力，基本上就是ReWork了，没有必要了。是不是能和Html模板一样方便实用？这个是真正的考验。抽象模型到实现模型的转换，需要先“理解”抽象模型，然后添加细节，最后拼装。其间有：抽象模型太复杂的困难，模板灵活性的困难，转换时机选择的困难，转换的效率。。。
————————————
早晨不大清醒的在白板上写下了：业务逻辑，交互逻辑，IT实现，表现实现。着魔了