![个人头像照片](https://ucc.alicdn.com/avatar/7094724e9e7746a2b03fe47f0f1816c5.jpg)
选一个好的挑战 - 把简单的东西想复杂 - 把复杂的东西做简单 - 把复杂的东西讲简单
在上一篇《业务团队如何形成统一的设计风格》中,探讨了一种业务架构的设计规范,以期达到这些目标:用标准约束技术细节;用技术工具而非文档推行标准;持续重构而非造新轮子;重视业务建模。但通篇表述较为抽象。本篇将总结团队近来的架构演进工作,以更具体的技术细节,详细阐释该理念,作为“统一业务设计风格”的实践篇。文中详述了多个层面的设计规约和基于规约的搭建方式,并在末尾回答了上一篇的诸多疑问。
首次上线应用,面对业务框架搭建你是否曾感到无从下手?维护线上应用,面对大量历史包袱你是否正避坑不及深陷泥潭?为何同样是业务应用,不同人的设计风格千差万别?为何最初的设计经过多个迭代后总是面目全非?新人来到团队,怎样才能快速了解业务,不被大量技术细节折磨?如果你也有这些困扰,希望本文能提供些许帮助。