目前应该没有很好的量化指标，或者我个人认为 DDD 根本无法量化

1.从战术建模层面上来讲，它那套东西本质上并不是原创，SOLID 跟设计模式里面早就有了，只不过面向对象建模对于粗制滥造的中国软件行业来讲不太适用，当然这是另外一个问题了，毕竟大部分公司活不到需要重构整个系统的那天，如果有..大多也是请人重写了，毕竟人力成本摆在那里，企业开发领域 例如 Java 生态如此之好，轮子都是现成的，搭好架子就能开始撸业务，基本上招几个老手带着一堆菜鸟重写整个系统简直是不要太便宜的一件事情了。

所以从战术建模层面上讲，你很难按说你的模型划分清晰在长远来看就能带来多大的好处，因为大部分时候大部分场景下业务系统都是重写了，而并非重构，因为重构至少得有单元测试跟说明文档，大部分公司能保证核心业务系统代码单元测试覆盖率到 80%以上就非常不错了。

2.从领域划分上来讲，真实世界的业务发展大多都是无序的，也并非是一个程序员能主导的，在大部分互联网公司运营比产研部门要强势很多，毕竟运营是直接给公司创造数据跟估值的部门，所以别说领域能够划分清晰，在一个系统里面想实现一个业务只有一个精确的表达都很难，因为我真就为了一个业务领导需求把一个跨部门对接的模块重新做了一遍，而且两个模块功能都是差不多的，只不过我这个模块又加了一些其它的业务属性配置维度。

另外这两个模块的配置是相互影响的，是不正交的，配置起来差不多类似 CSS，当然没有 CSS 那么复杂，但你一旦使用，就必须得同时关注两个功能配置模块，否则就会出问题，如果测试跟运营只使用先前的模块而忘记我开发的新模块，那么很有可能在属性配置上就会产生意想不到的结果，而我评估的时候就想到了这个问题，因为大部分人很难记住一件事情需要配置两个模块，而且运营人员之间使用这个系统也大多是口口相传，并没有规范化的文档，结果就是一年的时间里面，那个地方运营测试找了我不下 10 回，我跟他们解释了不下 10 回。

其实正交这个事情，现实中是有大量案例的，例如驾校老师跟你讲，开车遇到危险不要做除踩刹车之外任何多余的操作，除非你是开赛车的，而且像开车遇到危险这种事情还难免有些女性司机把油门当刹车踩，所以你要教导一些普通的人遇到危险还去操作方向盘简直难如同登天，还不如买个带 ABS 的车，遇到危险只管踩刹车就好，其余的事情交给上帝就好。

@sasalemma #30 这个倒真是 同一款 TP 的路由 能在 Openwrt 里面找到好几个版型的 ROM，说明厂家缩水很勤快啊..别的路由器大多就没这回事，要么就是直接发 v1 v2 这种新版上市

@kid740246048 #2 我希望板 u 内存 1500 出头 能搞定最好

@kid740246048 #2 zen3 看上去也很贵啊

价格越便宜越好，麻烦老哥推介一下

动手写一个 parse 照 innodb 写一个 b+树 按页 为最小单位实现

@dwSun #38 我刚验证了一下 Chrome 卡的要死 但是微信又是正常的 奇了怪了

@dwSun #37 这个卡不卡 貌似还要看软件的 我这边 Chrome 里面用搜狗就是卡的要死，换成操作系统自带的配置软件就好一些