关于更好的定义问题得到更简单的解决方案。大多数时候，其实我们是反过来的。 设计的解决方案过于复杂，开始思考有没有更简单的解决方式，思考问题定义本身是否可以调整，以满足我采用更简单的解决方案。 总的来说，如果一个问题的解决方案过于复杂，也许问题本身就有问题。如果解决方案很简单，那么快速落地好于琢磨出更好的问题定义。 我认为文中有个小点在大项目里才是最重要的，那就是获得信任。不止是业务方，涵盖所有利益相关方。 大多数时候我们目标不一样认知不一样，客观的理论观点其实是很难达成一致的，毕竟大家的视角立场不同，一味的强调正统方案的讨论，很容易将理性的沟通激化成感性的争执。所以在平时的合作中，从长期来看，建立信任比采用好的解决方案重要（两者并不冲突，对比只是优先级的权重）。那么要想建立信任该怎么办？要解决这个怎么办，留待徐昊老师的后续章节。

Word Smith 有点儿哲学家的味道了

感觉定义问题是为什么要做以及向那个方向努力，把问题定义清楚了，怎么解决是一个工程方面的问题。 文中描述的业务模型让我感觉像是业务人员与软件人员、软件人员与软件人员之间的沟通手段。

请问徐老师，业务架构师的主要工作是不是业务建模呢？ 业务架构和业务建模两者之间有什么本质区别呢？

和八叉兄学习下。写课不会耽误你做琴吧？😜

可以用及时雨来形容这门课程的到来！

很赞

我为什么要学习业务建模？ 之前听说过领域驱动设计，虽然也买过极客时间的专栏，然并卵…… 最近的工作以文案为主，希望能够学习一下业务建模；如果有机会，可能会接着学习《DDD实战课》。 主要关注能力或者效能评估方面，所以如何定义问题？ 受工作环境的限制，其实我对课程的旧约部分更感兴趣，或者说，我觉的只有先理解了“前云时代”的领域驱动设计，才能更好的理解“云时代”的业务建模。 置顶留言里面提到信任的问题，我觉的让业务方、相关方、甚至自己人，信任的关键，在于做好自己的事情，比如找准业务中的关键问题，能够梳理总结清楚，并且有效沟通。 有留言说到“模型”，我也觉得需要定义一下，我这边做的业务里面有“仿真建模”。 问题来了，由谁来做业务建模？

2 hard things: cache invalidation, naming things and off-by-one error.