扯扯平台开发那些蛋
最近做平台开发，极其痛苦。其实我也很迷惑，为什么别人的平台开发这么容易。我做起来就相当难受。
这个问题，不太容易找到答案。有以下两个原因。第一，没有相对标准，不能横行对比，我并不了解别的平台开发是怎么样的一个过程。第二，没有一个可量化的绝对标准，说明你改一个字段应该需要多少时间。
没有经验，摸石头过河，总是头疼的。既不知道有什么优雅的解决方案，也不知道自己做的是好是差。
所以我倒过来，思考。要什么情况下，平台做起来才舒服?
这个答案回答起来就很容易了。大家都希望，数据都已经在DB里面躺的明明白白的。需要什么功能，curd取数封装一下返回值就行。
另外，涉及的外部依赖少。不用做那么多沟通扯皮的事情。整个开发流程也是高内聚，松耦合的。不然一陷入扯皮沟通，那就容易没完没了，项目风险很大。
小结一下，做的需求功能，涉及的数据一定是内部DB里面有的。数据决定平台的能力上限。外部依赖(不考虑中间件，这里指业务逻辑需要调用别的系统）应该尽量的少。
为什么我做的痛苦呢？因为我一条不落，两条全占了。(想想，真想揍产品)。
那怎么从这种痛苦的开发状态，变到可以无脑curd的状态?这才是非常有价值的问题。
这里，我认为首先要明确平台希望解决的业务问题是什么?否则，数据库表一旦确定。后续再改，成本就和重新写一个系统差不多了。实在不行，尽量少改动数据库。但是现实情况，因为产品并不承担功能的成本。就好像逛淘宝买买买，结账买单的是开发同学一样。那产品肯定是买越多越好。指不定买的啥功能，就火了。这种类似委托代理问题，就不详谈。
第二，考虑分工。其实也就是业务架构设计。架构肯定是要考虑好技术问题。但，因为目前的技术发展。人力成本比机器成本要高的多。分工提升人效的收益，大于节省机器的收益。
因为组织架构调整频繁，我接手了许多别的团队的项目。了解到，很多时候我们因为组织架构的限制，所以我们做了这样奇怪的技术设计。为的就是少和外部团队逼逼赖赖。
第三，才是技术选型。业务场景解决的问题确定。往往，技术选型也比较容易。以分布式锁为例，考虑安全和性能，长事务还是短事务。都有相应的妥帖的方案。考虑安全那就用zk。考虑性能那就kv存储。金融特殊场景只能DB，且不能跨库。
但是，事务发展往往是动态的。我们不是一开始就很清楚业务领域的变化。我们也不是一开始就很了解自己喜欢什么，不喜欢什么。总要碰撞一些什么，才会明白。
从不清晰到清晰，这个过程中。我们肯定不能等到什么都特别清楚了才开始做。架构从来不是设计出来的，它是演进出来的。设计模式也不是设计出来的，它是按一些原则，逐渐演变的。
那如果从零开始，应该怎么处理一个平台系统呢？
我的答案是，从通用型系统，贴合业务形态，去慢慢演化。逐渐走上自研，做出业务特质的系统。
至于ddd领域建模，这个我觉得并没有很高的价值。这对于业务领域很成熟，只是需要迁移到电子平台上的业务，可以这么做。许多新赛道，整个赛道的玩法，认知，业务场景都在飞速变化。演进比建模要有意义的多。
