前言
在2014年左右，当时我们创业成立了一家软件公司，主要服务于中小客户，帮助客户实现业务的互联网化，我作为公司的技术负责人，一直负责公司里的技术管理+技术框架，我们主要做的产品形态以手机APP为主，在2016年年初的时候，我们团队已经有30多人，主要都是些软件工程师。然后好景不长在2016年底公司因为项目交付出了问题，导致资金链断裂致使公司倒闭了。如何才能做好项目交付？就成了我一个非常想搞清楚的问题。
后来，我们创业团队解散后，就各自在不同的赛道上继续创业了,当时我们团队在做汽配商场的产品软件，我们迭代产品搞了将近一年的时间，从18年10月份搞到19年底，我们技术上采用了前沿的技术，管理上也采用了敏捷项目管理模式，但最终的产品表现也很一般，抛开需求变更这些干扰只是从项目技术上来说，我也感觉没有那么让人满意，当时非常的迷茫，都不清楚该超什么地方努力才能做好项目？
在2020年，疫情开始以后彻底打乱了我们的市场规划，当时汽配行业受疫情影响非常严重，我们坚持到五一然后也就放弃了。同年在10月份，我加入了一家新三板上市公司，担任技术负责人。公司主要服务于政府/事业单位的客户，公司的人员规模与体量都要大很多。公司也始终与其他的兄弟公司保持交流，也借鉴很多大型企业的管理理念与方式，而且在2022年公司还获得了CMMI5认证，但是公司的项目交付上却也非常吃力，到底如何才能做好一个软件系统呢？
实践
上面说道的三段不同的经历过程中，我都在思考这个问题，也为此做了不同的实践尝试：
- 通过企业考核制度确保质量
- 通过采用前沿的项目管理方式
- 利用领域驱动设计+单元测试确保质量
三种实践的结果
实践一
由于当时我们没有完备的软件流程，且流程与流程之间的责任很多地方存在盲区，尽管我们设置了一套考核管理体系，但是由于大家对制度上不认同，反而让很多人产生了敌对心里，最终的结果是：考核失败、公司倒闭而结束。
实践二
我们把敏捷项目管理方式纳入到了项目管理过程中，同时也采用了腾讯的TAPD管理平台作为管理工具，严格的执行敏捷模式，每1~2周进行一次版本迭代，采用springcloud技术开发，通过CI/CD实现自动化编译与部署，上线前也都做功能测试，但是最终我们的产品质量也就刚刚60分及格。
主要的有如下几个问题：
1、经常事与愿违
在紧急上线的时候，无法完全走完预定流程。经常在上线的时候保持高度紧张，经常熬夜上线，但是百密一疏终有一漏，可能第二天一早就被客户的电话给叫醒。
2、测试覆盖不全面
测试尽管也有测试用例，但测试的方式主要主要是靠人，由于测试的精力有限，再加上通常半夜上线，导致测试往往每次部署后，主要关注本次部署的功能，而开发过程中经常出现把当前问题解决了，却引发了新的问题的时候。我们当时也期望引进单元测试实现对代码质量的监控，但是由于当时采用的是面向数据驱动的方式开发，单元测试落地成本极高，所以也是尝试了一段时间就放弃了。
3、陷入bug的死循环
由于没有良好的检测机制，无法做不到对功能的全面覆盖，不可避免的会导致系统上线后产生bug，而由于是在运行中的系统，带着bug上线致使团队不仅要面对新需求以及修复缺陷，还要投入很大经历在做数据恢复与数据的处理中。然而bug反反复复，然后就天天的写bug改bug了。
实践三
2019年，在我看了一篇名为《复杂业务代码要怎么写》的文章后，被领域驱动设计所深深的吸引了，然后就一头扎进了领域驱动设计的学习中了，我最开始对这个技术感兴趣，就是感觉能够用它来解决软件开发的质量问题，在2020年我几乎把我80%的兴趣都投身了领域驱动设计，然后在我在加入这家公司时，我也基本掌握了领域驱动设计的思想了，也就颇不期待的将这套思想模式引入了公司的当前研发体系。我当时经常激情澎湃的给大家做分享讲解，每次大家也都听的热火朝天，但是结果却是道理都非常认同，状态非常nice，就是不清楚该怎么做。我为了落地这套理念，也投入到一线带队参与项目的开发，但由于我在公司里其他的事情比较多就在一个月后脱离出来了，结果这个项目最终的结果却是“四不像”，最终也以理念落地失败而告终，后由被强行改回了数据驱动开发的三层架构。
分析主要的原因如下：
- 企业过度重视交付，不够重视软件本身
公司研发团队，一直都忙于项目交付，尽管很多个人对这套体系非常认同，但是迫于项目进度的压力，且自己短时间内也不知从何下手，就导致没法推动落地了。所以我一直认为，这次失败与公司层面不足够重视，没有投入太大精力去尝试有关。 - 大家过分的追求技术，不重视设计与思想
从事技术的人做的时间久了，无论是个人，还是客户，都比较喜欢追求技术，喜欢研究学习更前沿的技术，例如：人工智能、区块链、云原生等等。而相比领域驱动设计，就显得有些冷门，即便学会了也不能让你瞬间可以上天入地。再加上追随的人越多互联网上的资源也越多，反之亦然，领域驱动设计在互联网上的资料就非常的有限，而且还存在很多误导。当大家习惯了沉浸在当前熟悉的领域中以后，就更加难以脱离，而且对其模式都比较的排斥，，再加上领域驱动设计是一种编程思想，不是技术框架，所以更在难短时间内掌握。 - 缺乏系统的学习体系，缺乏对软件的敬畏
目前我了解到，还没有哪家学校或者培训机构会教大家该如何做好软件工程，领域驱动设计更也不在教学范围之内。唯一与领域驱动设计有关系的也就是面向对象了，领域驱动设计思想底层是就是面向对象，而很多人都认为面向对象只是面试时需要掌握的知识，基本是过了面试以后就都还给了老师。市场上缺乏对设计模式与思想的追捧，市场上更多的是对技术本身的追捧。
总结
如何才能做好一个软件系统？开始我是被动面对这个问题的，在此之前我从没有思考过这个问题，当时感觉自己的技术还不错，还拥有开源项目，也做过那么多的项目，处理过各种技术问题，总觉得做好项目，有我这个技术大佬在就没有问题。
后来我希望依靠管理的提升来解决这个问题，学习了《敏捷项目管理》、《OKR》、《一分钟经理人》，才有先进的技术与自动化的策略，但是最终却仅仅是及格的成绩。
在学习完领域驱动设计，我明白了什么是面向对象开发，也懂得如何将业务转变成领域对象，而且可以非常容易的对对象做全方面的单元测试，以保证软件业务的质量。同时也学会了如何通过领域对象来应对需求的变化，面对需求变化的时候，做到游刃有余。
我在公司里以EPG组长角色参与了CMMI5的认证，整个过程中我也都是带着问题去学习的，整个过程我的收获也颇多，不仅学会了如何通过数据量化分析的方式来支撑流程上的改动，也学会了如何通过数据分析发现出流程背后的问题，完成认证以后我在公司里也做了一个自我分享，整理了30多页对CMMI5的理解。整个CMMI5过程尽管是对软件管理能力成熟度做的评价，但是其本身并不局限在技术上，也不局限在某一个流程上，它是一套可以收敛的制度体系，只要按照其理念方式去不断的优化，最终就可以得到自己满意的模型。
我从12年工作到现在为止10年的时间里我曾经学习过非常多的技术，学过深度学习、区块链、大数据，也学过分布式、容器化、云原生等各种前沿的技术，但是最让我感觉的收获最大的还是DDD和面向对象。软件可也分两个维度，一个是术，就是各种技术体系，一个是道，就是设计思想、设计模式、面向对象等。道虽然难以理解，却不怎么变化，术虽然非常亮眼，却不断变化。
情怀
在18/19年，我当时在做分布式事务框架的时候，那时候很多出版社联系我，希望我可以出一本分布式事务的书。我没有去做，因为我感觉分布式事务就是一个技术框架，再就是不知道能给读者留给什么东西，我不希望为了出书而出书。
而在今年我想好了写的内容的时候，却已经找不到合适的出版社了，因为我想写分享面向对象开发和领域驱动设计的相关内容，而这类的书却因为比较冷门不被追捧，不好卖，所以出版社不太同意合作。
科学重于方法，不在于技术。个人感觉真正实现国产化软件崛起，要学习更先进的软件工程管理经验，要学习更先进的设计思想，而非技术本身。
我希望可以靠自己的这份微薄之力，能够让更多的人了解真正的软件工程，我目前也通过B站、GitHub同时开源分享了关于领域驱动设计相关的知识技术，也希望大家多多关注，因为只有更多的关注才能让更多的人有机会关注到。
GitHub
B站
推荐
如何做好一个后端项目
复杂业务代码要怎么写
领域模型、贫血模型、充血模型概念总结
分离业务逻辑和技术细节
设计模式