这句话矛盾吗? 应该如何理解?
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/ |