两年前，有几个出版社的编辑在QQ上跟我联系写书的事情，好奇为什么出版社会找到我这样一个很普通的.NET技术人员，其中一个编辑说他们分析了很多博客园博主的文章阅读量和写作质量，觉得我的博客还是不错的。尽管觉得自己写的博客不怎么样，但想着做了这么多年技术了，准备退居二线转行去创业，这个时候顺便写一本书作为技术生涯的总结到也不是坏事，于是和几位编辑沟通了一下，经过选题，最终和北航出版社签约写书。
此时时间是2018年8月，签了出版合同，我也辞了职，准备放松2个月再写。国庆好好玩了一圈正式开写，才发现写书和写博客根本不是一回事，而且当初签约的时候承诺要写25万字，就算每天写1000字都要写差不多一年，坚持了没几天就发现连续每天写1000字是几乎不可能完成的任务，写博客可以随便写，很容易写1000多字的水文出来；写书得写得有理有据，且不能粘贴太多代码，太多代码的书少那绝对是一本质量低劣的技术书。另外还有一个版权问题，编辑再三叮嘱版权问题与出版社无关，我不能抄袭别人写的内容。要不是我之前写了很多博客文章，完全靠自己写书的时候键盘现场敲25万字是难以想象的。于是赶紧跟出版社编辑沟通，编辑说不一定必须是25万字，不要比这个数少太多即可。听到这句话我心里稍稍安稳了下，于是整理了一个详细的写作目录，开始一章一章的写了。
第一章内容比较少，主要是程序员职业发展的问题，这些问题是我在CSDN论坛和各大技术QQ群里面收集到的一些讨论很多的问题，主要就是工作中天天写CRUD程序的问题，这使得工作了很多年的程序员都难以得到发展。正好我写的是SOD框架的书，整个框架就是围绕着如何更快更加简单的做好CRUD的问题来的，要解决这个问题就不只是如何造一个ORM轮子或者如何使用流行的ORM框架的问题了，而是要深入到数据和编程的关系上来，要深刻的思考数和数据的本质问题，这样我在整个第二章花费了很多笔墨来写，最后发现这一章远超了我的预期，它占据整本书的篇幅比例有点大，有可能使得一本技术书不是一本严肃的技术书，偏离整本书的重心。后来书写完以后，果然责任编辑对此提出了较大异议，要将第二章作为“附录”处理放到书的后面去。为此我与编辑沟通了很多次，我用霍金写《时间简史》的时候他的朋友建议他这本书里面要尽量少用公式来举例，“书里面每多一个公式将损失一半读者”，技术书的核心在于用浅显的话语把晦涩的技术问题讲明白，而我的第二章是读者能把整本书读明白的关键。
第二章写的时间比较长，一方面是我对如何写思考了很久，另一方面也是自己写的不太擅长的领域，毕竟研究什么是“数”的问题是一个比较复杂的问题，需要从传统文化领域去找答案。我认同《广雅》里面对数的解释：数，术也。如果说前者是数抽象的概念、符号，那么后者就是数的计算过程，且两者互为一体，不可分割，就像太极阴阳的关系一样，拿我们写的程序来说，数与术的关系就好像“程序=数据结构+算法”的关系一样，所以说明白了什么是数，那么就更容易理解什么是数据结构，什么是算法，最后自然就理解什么是程序，以及要怎么样更好的来写程序了。为了验证我的思路，我大胆的向我儿子就读的小学班主任申请，来给他们班免费上几节“少儿编程”课，其中有一个环节就是让同学们模拟原始人在没有文字，甚至语言都还没有完整使用的情况下，怎么样来理解数的问题。上课的结果让我很惊讶，小学生的形象思维更加容易理解数这个抽象的概念，甚至他们连太极、阴阳、八卦这些概念都理解了，整个课上得生动有趣。当然，这几节课直到上完，我也没有讲任何程序语言的事情，我可不想让他们去赶时髦教他们学Python，尽管他们学校也有信息课，教了一点scratch，但我儿子说这玩意太幼稚了就是一个玩具，没什么意思。所以至今我只教了我儿子一点点Scheme语言，在数学课上学以致用。就这样，我在第二章中写了原始人学数字的故事，以及古代部落结绳记事的知识，用Lisp来表示结绳记事的过程，来辅助理解数的概念。既然小学生都懂得起这部分内容，相信读者朋友阅读这一章不会有太大的障碍。第二章还介绍了河图洛书以及八卦的演绎过程，可以作为感兴趣的朋友深入研究，这样能更好的理解关于数的“形象思维”。
第三章“数据库应用开发”和第四章“对象关系映射（ORM）”这两者的内容我研究的还比较深入，所以写起来不是难事，最重要的是我之前写的很多篇博客文章此时正好派上用场，但也不是直接复制粘贴过来就行，需要系统化整理一遍，且不能粘贴很多代码影响阅读体验，所以书中很多帖代码的地方都能看到“此处代码略。。。"的情况。有SOD框架的老用户拿到后来我这本印刷出来的新书说这两章看起来有”很熟悉、很亲切的感觉“，这说明SOD框架的”简单易用“特点非常受老用户肯定。第五章“数据窗体开发”在现在Web应用流行的情况下，以及各种Web前端技术框架的大量使用下，这一章介绍的WinForm和Web Froms数据窗体开发技术显得有点“冷门”，但只要是用过的朋友都知道SOD框架对此的支持是很完善的，能够一行代码完成表单窗体数据的增删改查，且支持MVVM数据绑定。为了体现SOD框架非常易于开发数据窗体这个功能特点，所以尽管这一章内容不太多，但书中给的例子是我完全重新开始一步步手把手写的教程，其中的方法拿来即用，希望大家对Web Forms/WinFrom能够有新的认识。
第六章 “分布式系统架构与数据开发”算是我10多年架构工作经验的总结了，为了彰显书的主题，这一章里面介绍都是架构设计开发中跟数据密切相关的内容，包括分层架构的数据访问和处理，DDD/DCI架构、洋葱架构的一些概念，以及综合各种架构特点的“分布式混合架构”实战的内容，甚至探讨了如何有效的进行业务分析的话题。这一章还包括企业应用中常见的数据分布式、分表分库、读写分离、分布式事务的知识，介绍如何用SOD框架来更简单的实现这些功能。第七章 “企业级解决方案应用示例”算是第六章的姊妹篇，他们都是基于我在以前工作过的几个公司负责的一些重点项目使用的技术架构方案的实践介绍，其中“应用层事务数据复制“方案PK过了原公司项目后期空降的海归总监基于Java+MySQL的技术方案，实践证明这个方案对比MySQL基于binlog实现的数据复制在开发难易度以及性能安全性方面更有优势。
最后一章做了一些框架的资源介绍，以及一份感谢名单，还有一份放到“后记”的写作感言。等到写完这一章，才发现自己已经写了整整一年时间，时间已经是2019年9月，写完发现居然已经超过了30万字（不包括英文代码和空格这些），差点不敢相信自己这样坚持下来了，用“掉了一层皮”来形容不过分，甚至像另外一个写书的朋友说的，写完一本书都“写秃顶”了（幸好我头发天生很多）。
书写完了但写书的事情并没有完，上面说的只是写完了”草稿“，还需要自己校对以及编写书的前言、请朋友作序、写目录介绍等，其中有幸请到了.NET领域的标杆队长张善友同学和.NET Linux Web服务器Jexus作者”宇内流云“前辈做序，他们写完还差一位Java领域的专家支持，因为写书之前和出版社说好了”纯.NET的书不出“，市场上纯.NET的书比较少，出版社出于市场考虑不得不蹭热度出流行的书，比如Python的书如雨后春笋，以至于我这本书的上架建议写的是”大数据“类，虽然我觉得这个上架建议不太合适，但也没有更贴切的上架分类。最后终于请到了一个Java技术专家帮忙写了一篇序言，没想到他对我的书评价还不错，这让我有点意外。（参考他写的【序三】）。
一边约朋友帮忙写推荐，一边和出版社进行审稿校对。出版社要经过“三审三校”，流程复杂，与责任编辑的沟通过程“比较痛苦”，纠错别字都是小事，的问题是编辑觉得你有些地方写的不好，要进行删改，有些地方甚至要进行大段的删改，碰到这个事情你的心脏得要好才行。另外一个麻烦事情是要给出书中引用的图片和文字的完整来源，如果一开始没有注意这个问题到写书完了才来做这个事情是相当无语的，我在网上零星摘抄的文章部分内容大都找不到原来的网址了，编辑一再强调有版权问题“你自己负责”。事已至此，我自己负责就负责吧，身正不怕影子歪，我确实没有大段的抄袭过别人的文章，也没有使用过有版权的图片。稿件校审期间又遇上了两次新冠疫情，最后终于通过最后的校审了，时间已经到了2020年6月份才送印刷厂，等7月我拿到印出来的样书，距离最初完稿差不多又过了一年。拿到新书那一刻，已经完全没有了兴奋和喜悦的感觉，只是觉得这件事情终于告一段落了，当然还有后期结算稿费的事情，这里不表。这样，从签合同开始到最后上市，这本书差不多写了整整两年时间。
书写完书能不能卖出去成了新的问题，为此我建立了一个网站来宣传，给粉丝做售前售后服务，期间又是另一种心酸，这里先不表，感兴趣的朋友可以移步我的在线销售网站试读，以及读者的阅读和图书评价。
最后就是我昨天去北京最大的新华书店--西单图书大厦，在四楼计算机图书区域，偶然看到我的书放到了“大数据”的书架上，有点“悲喜交加”的感觉，“悲”的是我辛苦两年写的书在电商平台销量并不好（当然跟我的销售策略失误有关，也跟出版社的宣传推广有关），这两年写书对我创业和找工作带来了比较大的影响，把最重要的事情给耽误了； “喜”的是竟然能在线下书店特别是西单图书大厦看到“它”能在这里有一席之地，也心满意足了。