开始项目我个人非常重视几个基本的流程，在这里和大家分享
业务逻辑，草图，ddd设计和UML图，这4种工具是互相连接，相互帮助的。如果能让团队中的程序员理解与体会这些工具，相信你将可以很有节奏的控制项目，掌握项目的可变性！
主题 “开始一个项目的思考结构思考”中的结构说的太抽象，这里的场景是在开始一个项目时如何去思考内部结构，让团队有一个完善结构图，共同语言等。相信在多人管理下需要让大家同时同步，这不简单啊~
在开始的前提需求已经确定了，现在我们开始设计拼凑结构吧。
万物的开始我们必须对项目有所了解，这里称为“业务逻辑”，了解业务通常被认为是项目经理的事，如果你认同你可能是个码农，你的工作就是依照项目经理给你的工作，你工作就是完成就对啦。
所谓“知其然，知其所以然”，在编写代码在不知情的情况下完成代码，这代码的扩展能力决定是有限的，扩展的范围往往都是自己认知的范围。
为什么业务逻辑这么重要，一个程序员如果了解了业务逻辑，就能在设计对象时很好的去设计模块，如果是接到要编辑的模块，也能知道自己的模块是和哪个模块相关，在依赖模块还没做好之前，就有了准备，这是其一的好处。
其二，在编辑模块时，你可以判断是不是“过渡设计”，这句说怎讲？
过渡设计和随便设计很容易理解吧，但是要找出平衡是需要经验的。在不了解业务逻辑，就会知道这底线在哪里？在不了解项目同时你又是个勤劳的程序员，你就会永无止境的开多个接口。这行为可以确保开发的模块不会需要再改，不会有要添加的接口！可是……你会有做不完的工作，而且太多的接口，代码管理需要很强的等级才能编辑出来，息息相关的对象又要一直重构，看你不死！有些人有时间，一直拼命加班去完成，遇到这样的程序员，我会建议他花时间去了解业务逻辑，把省下的时间去学习更有价值的东西。
好的，说完业务逻辑的重要，接着就是ddd设计模式，ddd这里是业务设计。这并不容易（没有东西是容易的啦），要了解ddd设计之前必须必备业务逻辑，那业务逻辑怎么加强？怎么快速理解？
嗨~我能说的是：没有捷径，只有融入线下业务，泡在业务里面才能很好的吸收这项目的逻辑。给大家说个故事：我以前都是看表面为业务拟定项目操作，结果顾客最后不能适应，最后放着不用…… 这行为我之前都一直认为是顾客不配合，不去了解我为什么这么设计，最后我体会了一句经典的话“去改变他人的思想，不如改变去适应他”。使用你软件的用户不是每个都和你一样聪明的，即使你的操作流程比他目前线下的操作好许多，但他们就是没法适应，因为他们操作时是用多年累积的潜意识完成，一旦有人破坏了他们长久建立的潜意识，你知道后果咯！
ddd业务设计强调有充足的业务逻辑，有人认为应该花项目中的10%~20%去了解业务逻辑，但我认为你千万不要看的那么简单，因为后果会非常可怕，这里我就不多说为什么~ 我给个场景：如果花不多时间去了解业务，业务会出现漏洞，这时这里就放了个“炸弹”，同样的问题会一直重复，到处都是炸弹！当你在开始编写代码遇到问题或其他程序员问起你问题时，你就是点燃炸弹的人！叭叭叭~
你花10%~20%制作的结构就这样被你的炸弹给摧毁了！也许你是补丁高手，那你就继续补，让项目恶性循环吧~
我的经验是编写代码不花大部分的时间，而大部分的时间都花在没用的“重构”，“重做”，“debug”和“添加修改功能”。编写代码是一门内功，外功再好也不能胜过内功，只要需求确定（业务逻辑稳定）就能很顺的编写与分工！我是从工厂出来的操作员，以前都是看了很多很多重做，而重做的原因大部分都是人为，能在工厂工作的人对工作的热情有限，对工作就马马虎虎，结果制作的产品就有缺陷，到了检验的部门就被打回重做，恶性循环~
在完全了解业务逻辑后，接下来就是开始wireframe
草图！这东西要开发的好可以去看看我上一篇的mockplus。草图目的是为了和你的顾客有个沟通的桥梁，这样就能避免太多的误差。草图也是让顾客细节化他们口述的想法，让口述变成画面，顾客会非常喜欢这样的服务（相信大家已经·这么做）。如果你能在草图细节化，恭喜你！你绝对可以省下大部分的成本（在未来）！
草图也有遇到很多的问题，比如顾客的要求会导致草图撑爆，不能持续维护~ 奇怪？为什么会有这现象？通常不可能啊？这看你的业务和工具，好的草图可以挖掘顾客遗漏的细节。一般的问题发现都是在用户操作项目时遇到的，等到用户操作已经是完成项目的时候了……好的草图可以很具体的模拟用户操作，让用户操作中提前把漏掉的操作告诉你，这不就是省下未来的时间！你看多么棒！
可是草图不就是一张纸，没有操作，又怎么又更多细节？对！但是mockplus 不只是这么简单哦！
完成了草图，这回就是设计UML 图了，这图彻底表达了对象与对象的关系，你也可以了解业务与业务之间的关系。这里有一对多，多对多，继承，complex，属性等
设计这UML主要是可以和程序员沟通，通过这UML可以完成所有对象的调用，要完成这UML也不容易（天下没有容易的事）
UML图是ddd设计和业务设计的结合，了解ddd的人都知道ddd包括业务逻辑。这里我再强调一下，好的UML是可以预判在调用的场景，调用指的是在前台或后台使用对象的语法。好的调用就是用脑袋中的业务了解去分析怎么调用，比如：我需要动物类中的狗的尾巴长度，结果：animal.dog.tail ，就这么简单的调用。好的调用可以省去程序员的时间，让项目可以更快的完成！
UML还有另一个让人讨厌的事，就是匿名。在名词上要想出好的名词给对象可是苦差事啊~我的英文不好，词穷啊~ 如果你问我有什么好方法解决匿名问题，我绝对不会回答你的问题！跳~
总结：这过程虽然看似复杂，但能够一一具备我也不是一两年就搞定的，一切皆是平衡。设计项目过程毕竟不是一般的程序员能完成的，但是具备这条件绝对对你个人发展有着很大的帮助，让你成为一个更有价值的程序员。
