新自然开发
这几天在继续思考《以数据为中心》，也参考了别人反思 DDD 的文章《拥抱毒瘤 DDD！》。
发现一个业界尤其是业务开发可能比较严重的问题，就是喜欢从上到下，以抽象的需求话语驱动具体的技术开发，而不是从实际出发，从下到上。也就是想得太多，观察和实践太少，并喜欢用臆想指导实践。
可以学习下马斯克第一性原理，从自然规律和底层信息和技术入手，倒推上层的需求和设计，而不是靠臆想和片面的信息。
所以我升级了之前【以数据为中心】的思考，为【新自然开发】，让自然规律成为核心。就像实体产业比如机械建筑等注重物理规律和人身安全一样，注重软件开发的底层规律和安全问题。
一、数据架构
我觉得未来数据架构最重要，AI 直接对接数据就行，AI 根据需求直接动态生成前后端代码。
如果需求变了，再生成新的就行。但是数据架构应该不怎么变，因为这代表着系统的核心逻辑。
某种程度上，数据也算是【新自然开发】里核心的自然因素之一了。
因为数据不但是计算机处理的底层对象，也是各种需求依托的重要对象，很多软件本质上只是数据的外壳。
二、低业务架构
我有时候设想，业务人员想要低代码平台，那程序员可否搞个【低业务架构】。
有了这个架构，程序员不需要关注过多业务逻辑，而是更关注更接近底层自然的工程技术逻辑。
说实话，我觉得现在的软件还是太硬了。客户还是希望能按自己的意愿调整软件的，有时候软件不好按需调整，导致流程被卡死很难受。所以我觉得做工具，然后让用户根据工具按需调整是个大方向。
业务逻辑由需求分析人员分解为比较基本和规整的逻辑，交由程序员开发或让程序员提供工具，程序员不需要关注太多业务功能，业务功能可以交给业务分析和测试来关注。
程序员构建良好的技术架构和指标（这些更接近自然），降低对业务理解的依赖和耦合。将业务和工程解耦，就跟将建筑设计和施工解耦一样。
程序员应该做工具，而不是当工具本身。如果我自己开发游戏的话，我就先开发一些工具，然后再利用这些工具来做游戏内容。前者，我是程序员，后者，我是策划。如果直接用代码来写游戏逻辑，不断试错游戏想法的话，很不方便。
工作流和低代码平台不好用还是很多客户需要也说明了定制化确实是刚需。程序员终究还是要专注技术本身，而不能疲于被业务人员当工具用。
所以我这是反DDD的。DDD适合分析整理需求，不适合指导开发。DDD讲究开发人员充分理解业务，把本该清晰分离的需求分析和程序开发的职责给耦合在一起了。
我觉得更适合技术人员的脚踏实地的方案应该类似数据驱动开发这样的可以直接落地的方案，数据比领域要踏实多了。
三、算法=逻辑+控制
这两篇文章讲得挺好。和我的想法也有些匹配，业务就是逻辑，技术就是控制。让搞业务的和搞技术的职责清晰。