这是一个创建于 2399 天前的主题，其中的信息可能已经有所发展或是发生改变。
这句话矛盾吗？ 应该如何理解？
 |
1
Mitt 2018-05-28 19:41:55 +08:00
不矛盾， 架构是一种整体解决方案，这个解决方案是适用于实际的业务需求，ps: 楼下轻喷
|
 |
3
ibegyourpardon 2018-05-28 19:48:53 +08:00
我觉得还挺好理解的…
架构应该和业务独立，否则完全业务要 123，你就给个 123，那其实根本就没有架构可言了，这样的架构或者说代码大家多少都碰过，有多恶心就不提了。 架构还是应该从业务要的 123 里提炼出来，如果发现业务经常要的是 123 345 567 789，OK，找到规律了，提炼出来，和业务的耦合度减轻，无论为以后扩展还是更好的服务于业务都是应该做的。 然后说回来，服务与业务，意味着架构不是只是设计的爽就行，还是要为业务落地服务。业务只需要 123 345 这样的序列，你搞个架构设计到能提供 123 345 还能提供 1234567 3456789 这种业务上根本用不到的东西，那也是浪费，甚至可能给更贴业务层的开发人员带来额外的困扰。 |
 |
4
lujiajing1126 2018-05-28 19:56:16 +08:00
经济基础决定上层建筑，上层建筑反作用于经济基础
这就很辩证了 逃] |
 |
5
kunluanbudang 2018-05-28 19:56:20 +08:00 via Android
话术而已
也可以说成 架构源于业务，又高于业务 反正怎么说都对 不要浪费自己的时间 |
 |
6
surewen 2018-05-28 19:57:41 +08:00
架构为了解决一些问题而存在，但不应该只能解决这些问题。
|
 |
7
pandago 2018-05-28 22:08:11 +08:00 via iPhone
我觉得是一个抽象程度的问题 抽象程度为 0 这架构就是为这业务量身定做的 任何变动都是伤筋动骨 抽象程度非常高的话就需要很多的超前考虑 就像万能公式一样 考虑成本维护性扩展性等等取一个合适的中间值
|
 |
8
gevin 2018-05-29 08:53:40 +08:00
我的理解是，因业务量级变大而导致的架构的调整，就是架构独立于业务又服务于业务，前一个业务是业务架构，后一个架构是业务需求
我前几天刚写了关于架构的博客，不知道有没有用： https://blog.igevin.info/posts/software-architecture-and-business-architecture/ |
Select Language