背景
从去年开始写技术博客到现在我意识到写技术博客最重要的就是把场景描述清楚而不是零碎的去记录一个东西。
当讨论场景时候我们应该讨论什么
任何事情都得具体问题具体分析，我们先应该弄明白当前的context是什么具体要怎解决什么问题，应该怎么解决，会有哪些边界条件。
一个大系统中会包含很多小系统，我们可以把一个场景当做一个系统，这样一个大的场景中会有子场景。在这个场景中我们会有什么样的解决方案为此场景服务。显示工程开发中我们经常会使用以有的子系统，从而让我们专注于现有基础（子场景已经解决好了）和场景下如何解决当下的问题。
解决一个场景问题的时候，不管你采用第三方组件还是自己动手开发。你先得明白当前场景需要什么会有什么边界。明白了场景及其边界你才能够去选型（选哪种技术手段），知道自己要做的事情是什么。
说了这么一大堆我是在强调场景的意识（先把问题场景再现），也提醒我们不能把一些概念生搬硬套，先考虑实际情况是啥。有了概念会给我们一个锚定，基于这个锚定来连接其他概念从而形成关系。
我为什么这么想
我为什么产生上面的想法，是由于今天在用java copyproperties的时候发现spring的BeanUtils包不支持不同类型的转换。那我想当你使用属性copy组件的时候你应该想到该场景中会有什么样的边界呢？需要考虑的点有哪些呢？
假设 （source:A,dest:B）,如果要把A属性Copy 给对象B其具体场景会有什么要考虑的。
1.如果A中有null属性怎么办？
2.如果A中属性s与B中属性s类型不同应该怎么办？
3.如果A和B中分别有子对象C，A.C对象属性会copy到B.C吗？
明白了上述点后，我们就不会随便拿一个不满足要求的组件（比如我当时就用了Spring的beanUtils组件发现对于不同类型同名属性不能够copy）。
