如何理解 “架构独立于业务又服务于业务”？

[checgg]

这句话矛盾吗？ 应该如何理解？

[Mitt]

不矛盾， 架构是一种整体解决方案，这个解决方案是适用于实际的业务需求，ps: 楼下轻喷

[lookwi]

@Mitt 一楼说的对，任何架构都要落地，否则就是耍流氓

[ibegyourpardon]

我觉得还挺好理解的…

架构应该和业务独立，否则完全业务要 123，你就给个 123，那其实根本就没有架构可言了，这样的架构或者说代码大家多少都碰过，有多恶心就不提了。

架构还是应该从业务要的 123 里提炼出来，如果发现业务经常要的是 123 345 567 789，OK，找到规律了，提炼出来，和业务的耦合度减轻，无论为以后扩展还是更好的服务于业务都是应该做的。

然后说回来，服务与业务，意味着架构不是只是设计的爽就行，还是要为业务落地服务。业务只需要 123 345 这样的序列，你搞个架构设计到能提供 123 345 还能提供 1234567 3456789 这种业务上根本用不到的东西，那也是浪费，甚至可能给更贴业务层的开发人员带来额外的困扰。

[lujiajing1126]

经济基础决定上层建筑，上层建筑反作用于经济基础
这就很辩证了
逃]

[kunluanbudang]

话术而已

也可以说成
架构源于业务，又高于业务


反正怎么说都对

不要浪费自己的时间

[surewen]

架构为了解决一些问题而存在，但不应该只能解决这些问题。

[pandago]

我觉得是一个抽象程度的问题 抽象程度为 0 这架构就是为这业务量身定做的 任何变动都是伤筋动骨 抽象程度非常高的话就需要很多的超前考虑 就像万能公式一样 考虑成本维护性扩展性等等取一个合适的中间值

[gevin]

我的理解是，因业务量级变大而导致的架构的调整，就是架构独立于业务又服务于业务，前一个业务是业务架构，后一个架构是业务需求

我前几天刚写了关于架构的博客，不知道有没有用：
https://blog.igevin.info/posts/software-architecture-and-business-architecture/