如何将复杂的应用逻辑从存储过程移植到业务层

>> 按照DDD的设计理念,设计始于业务实体和服务,而不是传统上先设计数据库表,因为数据库仅仅是一个数据持久化的地方，我们应该抽象出数据存储，放到什么存储介质都可以，但现实有很多情况不得不违反这一原则，

其实，更多的时候，数据存储方式是一种需求，而不是你可以选择的设计方案，目前很少会有客户同意将业务数据存放在非RDB中吧。所以大多数情况下，分离这两个层次不是为了能够提供多种存储方式，而是因为它们属于不同的抽象层次。

>> 比如大数据的计费应用，必须把应用逻辑写到存储过程中,如果严格在业务层来处理会带来性能的问题，试问各位有没有好的办法解决这一问题．

两方面无法兼顾。在大多数情况下，交易从存储过程移到外边应当不会有太大的问题，不过有一些确实影响性能的处理你还是可以放在存储过程中。

你只能用一种方法解决99%的问题，而另外的1%的问题你需要各种各样你想得到的方法来解决。

>复杂的应用逻辑从存储过程移植到业务层
那就是从起点出发，更换一套全新的分析思维，从对象建模开始，找出模型对象，而不是数据表，完全抛弃数据表概念，使用Hibernate等这样O/R架构，这样，数据表概念从一个软件的分析设计编程几个阶段一个都进入不了，就好像你从来没学过数据表一样。