周一来到，小明接手了一个需求。
要搞一次促销抽奖活动，奖池里配置了很多奖项，我们需要按运营预先配置的概率抽中一个奖项。
解决思路貌似很简单，生成一个随机数，匹配符合该随机数生成概率的奖项即可。
实现貌似也很简单。
很快，弄了两张表。
很快，弄了三个类。
很快，搞定，上线，花费时间不到半天，小明很得意。
可是，需求变化也很快。
产品经理找到小明，规则变化了，要增加过去两个月内购买过10个订单以上的用户才可以参与抽奖。
小明应该把代码添加到哪个位置呢？
需求再次变化了，未来三天购买订单数满足跨店才能参加抽奖。
小明应该把代码添加到哪个位置呢？
即使后面来的两次需求，都找到了自己的添加位置，第四次、五次。。。呢。
每次添加新代码的时候，如何快速的定位？
开发完成后，测试人员要不要全回归测试呢？
毕竟你都改动到了好几处地方了，如果不全回归，以前的代码会不会有问题呢？
如果这样都做了，后面没增加一个需求变化，到底是快，还是慢了呢？
业务逻辑复杂了，业务的逻辑、状态会散落到大量方法中，你没有抽象，就没有办法模块化，就不能区分核心和周边，需求越来越多，你就只能硬写，你的这种硬写，往往都是写到了核心模块里面了，之所以成为核心，不就是希望你不要总是改变它吗，要尽可能将其变为只读的，否则，你当初的快就是后来的慢；
上面的编程方式是哪种方式呢，什么编程风格？
基于“Service 贫血模型”的实现。
大家，为什么总是习惯用上面那种方式编写代码呢？
可能是业务简单到就是基于SQL的CRUD。
可能是在service层中可以定义任何操作。
可能是思维已固化。
可能是转型成本太大。
可能是。。。
如何应对变化，如何不让当初的快，变成后面的慢呢。
就是要千方百计地将核心模块和周边模块，变成正交性的设计，让核心模块变成只读，每次来一个需求只需要修改或增加周边模块就好了。
那如何才能一步一步实现正交设计的代码呢，最原始的基础就是要用丰满的面向对象技术，用丰满的面向对象技术的基础方法又是充血模型。
基于贫血模型的传统的开发模式，比较适合业务比较简单的系统开发；相对应的，基于充血模型的 DDD 开发模式，更适合业务复杂的系统开发；比如，包含各种利息计算模型、还款模型等复杂业务的金融系统；
应用基于充血模型的 DDD 的开发模式，需要事先理清楚所有的业务，定义领域模型所包含的属性和方法；领域模型相当于可复用的业务中间层；新功能需求的开发，都基于之前定义好的这些领域模型来完成；
越复杂的系统，对代码的复用性、易维护性要求就越高，就越应该花更多的时间和精力在前期设计上；而基于充血模型的 DDD 开发模式，正好需要前期做大量的业务调研、领域模型设计，所以它更加适合这种复杂系统的开发；
好了，小明也觉得使用丰满的对象编程技术，会比较好。
那问题来了，小明需要第一次，就按照这样的编程风格编程吗？
第一次就需要考虑那么的周全吗？
第一次就需要面向未来设计吗？
我个人的建议，你可以被子弹打中一次，但是不要被打中第二次。
为什么这样说呢。
对这个图还有印象吗，整洁架构，向内依赖，最”内“里面是什么呢。
是个领域模型。
如果你第二次，第三次依然没有抽象出领域模型，你的每一次以为的快，都是为后面每一次的慢，埋下了“因缘”。
有没有好的策略，来指导如何判断要不要搞成所谓的领域形式呢。
个人建议：
1、判断是否你的程序只为一个业务方服务。比如财务人员要用到、营销人员要用到、运营人员要用到。如果是，就要提前考虑沉淀出业务领域模型。
2、判断是否你的程序只为一个业务模式服务。比如拼团业务要用到、国际业务要用到、健康业务要用到。如果是，就要提前考虑好业务身份的判断且抽象共享服务。
有没有好的原则，我按照这样的原则进行设计，进行开发就是能符合”高大上“的技术范的领域模型呢。
个人建议：
1、SOLID设计原则和23设计模式，优选SOLID设计原则。你问我为啥这样选，打个比喻的话，SOLD就像独孤九剑，23设计模式就像九阳真经。练招式起步容易，而且那些SOLID原则里面所包含的内容的内核，你只要”细思极恐“下，暂且用这个词语，一样能有一翻“洞天”。
练习独孤九剑也需要悟得。
当你可以将这其中的5个设计原则能够融汇贯通的时候，也是你的任督二脉打通之时。
当然，还有其它简单易行的原则，比如DRY、KISS、YAGNI、LOD等等。
2、增加辅助措施，没有规范，则显凌乱，若要有序，执行编程规范，同时把代码重构养成日常行为。
小明想，思维建议策略有了，设计指导原则也有了，有没有代码让我学习一番呢。
如今，学习，最不缺的就是代码，看开源软件。
Tomcat程序就是非常优秀的开源软件，你不会不这样认为吧，你的程序打包都发布到它的容器里面了，这里面有非常优雅的设计。
试想，Tomcat这样的web容器是怎么样接收我们的http请求的呢。
我们的queryOrder请求为什么就被送到相应的动作上执行的呢。
Tomcat要为每一个请求都加一个if else来判断，才能实现不同动作请求到不同类文件上面吗。
如果都加上这样的if else判断，是要在业务类里面增加吗，那不就跟业务类耦合了吗。
因此，Tomcat的程序的设计者们，想了很优美的设计思路。
他们发明了 Servlet 容器，Servlet 容器用来加载和管理业务类。HTTP 服务器不直接跟业务类打交道，而是把请求交给 Servlet 容器去处理，Servlet 容器会将请求转发到具体的 Servlet，如果这个 Servlet 还没创建，就加载并实例化这个 Servlet，然后调用这个 Servlet 的接口方法。因此 Servlet 接口其实是 Servlet 容器跟具体业务类之间的接口。
图自 李号双
这个设计里面，充满了浓浓的我们先前说的SOLID味道和正交设计的味道，你可以找出来吗。
