历时5个月的开发，终于可以交付使用了。在这期间系统从需求分析、系统架构设计、开发、测试、运行、迭代、交付，整个忐忑波荡的一路走来，终于有时间静下心来写一篇总结跟各位博友一起探讨、学习了。如果对大家有帮助了希望大家点下支持，推荐。
业务分析
随着信息化的发展（这东西发展真快），相信大家或企业越来越意识到企业内部信息化建设的重要性和优越性，我所接手的这家客户也是。之前是用友系统的客户，由于公司业务的发展，系统无法支持公司内部业务的发展，还有，抛弃原有系统的使用，打算定制开发一套符合自己公司业务运营的系统，于是本人参加了这个项目，并带领我的团队（朋友一人,哈哈）参与了这个项目的开发。
由于一些业务信息的敏感问题，我把部分信息的用XX替换了，表示该公司的一些特定内容，当然大家做需求分析时结合自己的情况在这些项目上去追加符合自己的实际业务内容就可以了。如下图这家公司的业务分析汇总。
业务设计介绍
订单部分
对于任何企业或者公司甚至是个人都一样，大家在进行任何买卖操作时都会去创建订单，以此来确定自己的购买计划、生产计划、销售计划、、、、、、对于这些订单的情况，系统需要有一个非常明确的业务数据支持和订单业务流程支持，而满足这些数据的支持需要你与你的客户做深入的探讨和分析系统去如何设计(由于本人开发过程中是敏捷开发，基本都是code 完个界面, 然后确认完后进入下一个 code界面 ，没有系统设计，导致了表字段的不足，尤其是后面业务统计功能时，严重的缺少些冗余字段导致统计sql 过于复杂)。
对于订单的制定，相信大部分系统基本是对于一些表单的维护，订单部分就是这样了，对于订单制定完后下一步，公司会基于这些订单去做相应的预算。其实预算无非就是把若干的订单合并到一起，来支持某个产品的生产或制造。当然对于这个预算单还是复杂度会根据你的产品订单的情况来决定的。
合同部分
对于合同部分，这家公司的业务是对于审批通过的订单回去生成合同，因此大部分的订单的归属是生成合同，在这个模块中最大的坑是合同的模板问。其中模板的选择和打印如何去封装好以及满足灵活的更换，这块本人也没有太多涉猎，希望万能的博友对于打印方面有独特见解的予以帮助，合同的制定业务过程还有复杂的地方就是合同条款，对于合同条款部分会有各种的约束，如付款情况的条款、结算情况的条款、交货、验货等条款的约束对后续业务流程的影响，也是设计人员在设计过程中需要着重考虑的（否则这里会是一个大坑）。
付款部分
对于付款部分，金额的管理是这个环节最重要的部分。对于这个金额管理合同的初始金额、每一笔的付款金额、最终的结算金额、最终的付款金额都需要系统在设计时做好充分的考虑，标准系统不知道怎么去设计的，这个流水账付款（如我们系统付款申请付错问题，实际付款和申请付款出现错误时）问题，我们和业务最后考虑是在结算时把之前的错误款项对冲回来，不然系统确实挺复杂的（不知道大家有什么高见么）。
结算部分
对于结算部分，业务还是蛮简单的，只需根据合同的物料明细做物料明细的数量确认就OK了，补充发生的扣款情况(扣款明细)、汇总物料的结算总计就OK了。
总结
至此业务分析就差不多了，如果你也是在做需求分析的话希望这些对你有所帮助，当然我写的很简单，发现确实越来越懒了。如果有什么需要讨论的，如论是技术还是业务欢迎加本人 QQ群33176382
系统架构
从业务分析情况来看整个公司的业务流程是订单确认阶段----->订单执行阶段----->订单付款阶段-------->订单结算结算，在每个阶段中的数据都会有相应的审批阶段为了满足系统的运行有相应的统计功能模块，系统基础数据设置（如数据字典等），系统设置(如人员、权限、组织结构、角色等)
相信大家最关心的是代码了好了现在上码（难道大家不喜欢无码的么？ O(∩_∩)O ）
解决方案
对这些SOA的设计来说基本都是类似的，如果大家愿意研究更多推荐ABP，我也是研究它结合自己的开发经验这样设计的。
对了这是一家服装外贸公司的项目，如果大家需要的话可以邮箱联系qianthinkover@163.com，当然我肯定不会免费的啦。需要的话邮件里聊吧谢谢大家的阅读，对于框架里面的一些代码封装，我有时间会开源的，上一篇Excel NPOI的封装代码还没上传，还需要整理。大家见谅。