🤔☕️🤔☕️🤔 * 📖：需求转化为任务，实现从问题域到执行域的映射。如果遇到粒度划分问题的挑战，解决之道是进行任务边界的划分。这几个信条该具备：可打破现有执行边界、有确定的决策优先级、最小化架构目标之外的抽象、最大化隔离、面向未来最优。 * 🤔：这个需求大家是否都清楚，跟这个需求是否大家都认可，这中间可能是个巨大的裂缝。我自己的经验，这个裂缝里刚开始可能只有空气，后面会有水灌进去，最终会变成酱缸。产生这样的情况，一方面可能来自历史的缘故，导致各种不信任，另一方面更可能是利益无关或利益冲突。这些问题，看似非技术问题，是否可以通过架构来解决，或者架构能对此改善？以我现在的认知，如果此时的架构，仅指技术架构，这顶多解决在如何，即How层面做到最优。如果把组织架构和业务架构放进来，前者，组织架构去解决我们是什么，即What层面认清自己到底要什么，后者，业务架构去解决我们如何能赚钱，即Why层面认清为何能赚到当下和未来的钱。前提条件，那就是大家都能有这样的共识，或者，大家都认可某人的领导力，由他来带领大家跨过裂缝，这样就有机会打破现有的执行边界。只要执行边界能打破，后面的共识建立起来，就是大家都坐在圆桌上讨论，而不再是在每个峡谷对面呼喊，还假装没听到的样子。 * 🤔：增加信条：“粒度划分越难的地方，越可能是最有潜力的地方”，所谓的越难过越得过。某个点的粒度难划分，可能是这个点本身我们不熟悉，这次下来弄明白，我们的能力就增长，还可能是我们的组织结构不合理，这次行动下来，可以优化组织。 * 🤔：去掉抽象，不会妨碍太多，过渡关注抽象，反而绊手绊脚。如果一个业务持续有发展，持续有新需求和变化，那么在这个过程里去抽象还来得及。最担心的就是，刚开始抽象得特别完美，然后就没有然后。

老师的这几个信条,在我看来是从不同的角度出发考虑的问题。 譬如 信条一,任务边界可以打破现有的执行边界,这条是从项目经理跟产品经理的角度出发,对开发任务的合理划分和分配; 信条二,任务边界划分有确定的决策优先级,是从CTO的角度出发,遵循之前定下的架构目标; 信条三,最小化架构目标之外的抽象;信条四,任务边界划分时要最大化隔离;信条五：任务边界划分要面向未来最优,则与Robert C. Martin在<<架构整洁之道>>里提出的SOLID架构原则暗合。其实就是我们老生常谈的架构师,从产出合理的解决方案的视角出发得到的结论,做架构要符合单一职责(一套代码面向一类人的需求)和接口隔离(面向不同人群需求的代码需要彻底隔离开),依赖倒置等原则(为未来留出抽象空间)。 如果从这个角度来看,思考题1说的是,研发资源有限性,架构目标合理性跟解决方案合理性之间取舍,三者并不是有你就没有我的关系,而是你中有我,我中有你的关系,因此三者不应该是稳定不变的状态,而是不停地在变,有一个动态平衡的过程,资源紧缺那就先优先级高的事情,感觉目标不合理了,不断地纠正目标,解决方案则一定要按照架构原则,围绕着架构目标来做,不然的话即便短期有收益,长远来看还是会给系统留下坏味道。