有些数据订单并不认识，不知道它的业务含义、无法解释它的结构、无法进行数据校验、无法确定这个数据的正确性与数据丢失对其它方的影响，这样的情况下，订单系统应不应该落这个数据？
有些数据的主键已经落在订单上了，比如参加活动的ID、商品SKU的ID等等，但是因为展示或者减少调用的诉求，还要额外将相关信息也落到订单上，比如活动内容、金额、补贴额度、时间、生效限制等等信息。这时怎么判断哪些信息应该落哪些不应该落？

营销在目前大部分互联网公司里是最重要的一块，并且这个领域是一个越来越大的趋势。你看京东618、天猫1111以及拼多多上的各种活动玩法，这些背后是营销大域的系统在支持。经常有BU为了搞一个大促或者做一波拉新，会有各种新鲜的、脑洞热乎的想法以及IDEA诞生出来，营销系统很容易像一个八爪鱼一样衍生出无数的分支进而承载各种玩法，常见的几个问题：



公司几个月后大促，要搞一个极为复杂的玩法，一边要利用之前的系统，比如积分、红包的基础能力，一边要通过社交、通过打卡、通过VR、通过一套复杂的任务或者游戏组合并发放新的权益。这时候老系统支持不了、或者新老系统交互复杂、或者没人说的清楚该怎么做，最后很多“硬链路”都是常态。
即使单纯一个红包系统，公司上游会有无数个系统、无数个业务BU，为了自己的业绩，都在发红包，红包发出去多少，成本怎么分摊，ROI是怎样的，无人知晓。

这些都是常见的问题，你说是领域设计的问题也好、是业务建模的问题也罢，基本上都要具体的Case By Case去看才有结论，并且也只有放到业务场景、项目需求中才有证伪的空间。从我的经验看，有两个切入点会让你更容易去厘清边界：首先要定期的去review项目的结果和协作过程的痛苦，边界的问题往往会暴露在这，要定期去看去清理。其次要每隔一个大的周期结合你老板的视野去看你们的大图，按照未来的业务发展去重新定义它，通过大动作去调整组织和资源进而改变协作关系和权责分工。这其中的很多问题未必是三言两语能说得清，不要强迫症非死不可，也不要视而不见，关注平衡。非常推荐找一些系统设计的书来看，尤其是讲耦合与内聚的，对大需求大项目做总结，设计这个东西大部分是经验值堆上去的，做的越多Sense越好。

Code Kata

augustbradley 的 Youtube 视频
Notion Book Reading Database — The Book Vault

阮一峰的网络日志
科技爱好者周刊（第 116 期）：世界的未来是一个火药桶

土豆不好吃
家用简单监控系统

What isgood code? These are a few of its characteristics:❑Good code is extensible without drastic modification. It's easy to add features withouttearing it apart.❑Good code is easy to read and maintain.❑Good code is well documented.❑Good code makes it hard to write bad code around it. For example, objects expose clean,easy-to-use interfaces that promote good use. Both good code and bad code breed.❑Good code is easy to test.❑Good code is easy to debug. Remember that even if a piece of code works perfectly, it's still aproblem if it doesn't favor debugging. What if a developer is trying to track down an error inimperfect code, and the stack trace disappears into perfect but obscure code?❑Good code contains no code duplication.❑Good code gets reused.

稍后阅读的服务，有人用 raindeop.io 嘛