架构第一原则：架构面向问题，但满足需求

市面上大量”面向XX的架构方案”（面向企业、面向互联网络解决方案等）背后其实是商业行为：推广者渲染自己在某方面的成功案例，寄望客户直接复制这些结果，却几乎不会有人真正深入你的系统去指出问题所在——因为一旦系统没有问题，方案提供商也就没有生意可做。这类”面向需求”的方案通常瞄准”同类系统的同类需求”，恰恰不考虑具体系统的背景，而现实中的系统问题是无法脱离背景讨论的：同一个”性能较低”的需求，选择某个技术方案在一个团队里是正确答案，换一个缺乏对应技术人员的团队里却是制造新问题——需求本身脱离背景是可以被满足的，但问题却未必因此消失。”面向问题”首先是客户视角的转变：客户很难从系统角度识别问题，只有当客户把供应商当作”合作者”而非”采购-供应”对立面时，问题才可能被提出；一旦双方站到”共同解决问题”的立场，需求的持续变化就可以通过对问题的阶段性梳理来消化，而不必疲于奔命地追着需求跑。”面向问题”也不会与具体开发实作冲突：即便架构决策是”数据建模推迟到第二阶段”，也不意味着放任开发人员随意就地实现数据结构——架构仍需在第一阶段约定数据规划必须限于当前应用的数据层、必须通过不涉及具体实现细节的界面向应用层交付、涉及多应用时须经架构角色确认，这些约束既隔离了问题、又没有对具体实施造成过度干预。最终，只有把架构的思维对象锁定为”问题”而非”变化的需求”，架构才有长期与持续性的存在依据——需求可能相同但问题未必相同，需求可能被满足但问题未必因此消失，需求可能破碎而问题却恒久弥新。

结构图：

flowchart TB
  A["面向需求的方案<br/>瞄准同类系统的同类需求,不考虑具体背景"]
  A --> A1["需求可被满足<br/>但问题未必消失(如.NET方案案例)"]
  B["面向问题的转变"]
  B --> B1["客户视角:从'采购-供应'对立<br/>转为'共同解决问题'的合作者"]
  B --> B2["开发视角:架构仍可约束实施边界<br/>(数据层限定/界面交付/多应用需架构确认)<br/>而非放任'面向问题'变得空泛"]
  B1 --> C["架构的思维对象=问题<br/>而非持续变化的需求<br/>→架构获得长期持续性依据"]
  B2 --> C