【技术管理者成长系列2】商业如何驱动架构设计？成为架构师前要先懂的8件事最新消息

图片来源:

技术管理者论坛

在台湾不少技术管理者或技术主管，在公司内也担任架构师的角色，但相较于国外，过去在台湾少有架构师公开分享自身架构设计的实验经验，不过，近日在一场线上技术管理者论坛上，鼎恒科技应用产品设计中心协理林承毅，大方传授多年来担任架构师的工作经验，不仅教导开发人员怎么学习平衡开发与架构设计之间的工作，更分享他如何透过商业来驱动架构设计。

林承毅过去在博奕产业IT待了十多年，一手主导不少大型软件架构设计，来因应各种大流量与高并发的应用场景，对于架构设计相当熟谙，后来进到鼎恒科技，更带领其中一个产品研发中心团队，负责应用产品设计与开发。

第一件事：架构师和开发人员的本质不同

许多人用蜕变升级来形容，资深开发人员成为架构师的过程，但林承毅认为，从开发人员到架构师，更像是一种转职的过程，等于是个人职业生涯的大转换。因为，取得架构师职位后，意谓著，开发人员有可能必须放弃习惯持续精进的技术能力，转而提升视野，增加自己的技术广度。他也以自身为例，担任架构师几年来，虽论开发技巧或开发能力，公司比他厉害的人不少，但他对于知识掌握更多，更广，可以看到更多不同面向。“这是本质上，架构师和一般开发人员的差异。”

第二件事：单有技术深度不够，架构师还必须持续增加技术广度

架构师需要建立自己的架构思维，主要有两个面向，一个是技术深度，一个是技术广度。

他也说，绝大多数的架构师，成为架构师前，通常是IT团队里最资深且技术最扎实的开发人员之一，这些人会对特定技术持续深入学习，一直不断累积实战经验，增加自己的技术深度。然而，成为架构师后要面临的问题，不仅仅是技术问题，还包括商业领域问题、安全问题、部署环境问题、公司组织文化问题，甚至还有预算考量和法规限制。

正因为时间有限，需要处理的问题实在太多，所以，架构师很难像以前一样有足够时间持续精进技术深度，只能在技术深度与技术广度两者之间，尽可能取得平衡。

为何架构师需要足够的技术广度？林承毅解释，架构师必须要能看出不同解决方案的差异，甚至分析好坏，才能判断出还有哪些类似问题可能影响原本的架构设计。而想具备这样的判断能力，重点不是对技术掌握多深，而是要有广度，才能够很快找出方案中潜藏的问题点。所以，持续增加技术广度，对于架构师来说很重要。

第三件事：学习平衡开发与架构设计之间的工作

不光如此，团队中的架构师，得学习平衡开发与架构设计之间的工作分配。通常在决定好架构设计后，多半会认为该由架构师负责核心与最底层的开发任务，听起来没有问题，因为架构师最了解自己的设计，但他指出，这样的作法，衍出生另一个问题，当整体架构出问题，往往只靠架构师自己解决，其他人很难给予协助，这就带来瓶颈。例如架构师离职了，就没人懂这个架构，久而久之，原来好的架构设计，会变成团队必须背负的技术债（或称祖产），“当你架构没办法演化或进化，你的商业模式是很难再进化。”

对于团队开发与架构设计，林承毅建议，较好的合作模式是，架构师先决定好框架和架构设计后，交由团队其他成员来负责开发任务，让架构师只需负责跟业务相关的开发任务，这样的好处是，一来让架构师有时间可以持续深化技术不至于与技术脱节，二来团队成员也能对于架构设计有更多了解，知道开发核心样貌。

第四件事：架构设计过程深受关键需求的影响

开始设计架构时，架构师会依据需求来做取舍，决定整体架构设计样貌。确认需求有很多方法，林承毅也说，其中一个是可通过ADMEMS需求矩阵进行需求结构化，进而得到需求全貌。一般来说，这些关键需求大致可分为功能性需求、约束性需求与品质需求，这些需求都会影响到架构设计，而从需求提取出来的架构特性，可以帮助架构师有效控制需求复杂性，并降低架构设计失败的风险，以及作为架构设计冲突时的取舍依据。

第五件事：运用DDD方法论将技术架构与商业架构对齐

正因为许多架构师，都是从开发人员、资深开发人员一路往上爬，林承毅有感而发的说：“成为架构师以后，免不了在设计架构时，容易只从技术角度来设计架构，以致于，最后要将商业模型放进架构时，才发现设计出问题，需要牺牲架构其他部分。”所以，他建议，架构师得拆解原本的技术架构，想办法让这个架构能够与商业架构对齐。

要对齐商业架构，也有各种不同作法，他表示，其中一个作法就是可以采用近几年因微服务盛行而窜红的领域驱动设计（Domain Driven Design,DDD）方法论，透过这套方法论，能够从业务相关的领域知识、对问题与解决方案进行切割，找出商业问题边界、技术边界、人员沟通一致性边界，进而理解软件架构需要解决哪些商业问题及其边界范围。他也提到，要让技术架构能够对齐商业架构，架构师可以透过DDD方法论中提及的Bounded Context与Subdomaion观念，来定义问题与解法，建立一个通用语言让团队能够彼此一致对话。

林承毅也说，当我们设计的技术架构跟商业架构能够互相匹配，就能够透过商业变化来驱动技术架构上的变化。当技术架构进化了，自然会带动商业型态再一次改变。“这是业界明显可以看到的现象。”

第六件事：架构师必须经常取舍，才能达到持续改善的目标

林承毅表示，持续改善架构设计过程中，架构师会一直面临取舍，甚至有时得放弃一开始认为不错的架构优点，并接受原先认为有问题的缺点。他补充说明，这是因为最初的缺点或优点，会随着整个商业模式、营运方式、架构设计而改变，“ 缺点不见得永远都是缺点，优点不见得永远都是优点。”

因为如此，他强调，架构师必须要了解不同架构设计风格，会带来哪些影响，比如为了调整服务间的通讯方式，提升整个架构的灵活性，而改采用事件驱动的架构风格，虽然有其好处，但缺点是架构变更复杂，维护不易，不仅架构整体容错性需重新设计，同时要避免事件本身在版本差异上造成的冲突。“所以在选择架构风格时，架构师除了需要知道它可能带来的负面影响，也得让团队理解需要承担哪些风险。”他说。

第七件事：建立架构设计该有的基本流程与方法

林承毅以一张团队协作的流程图，来说明建立架构设计该有的流程与方法。从这张流程图可以看到，一开始，团队与领域专家和使用者对话，针对公司的商业目标、问题、需求来彼此沟通，发展出属于自己的通用语言，借由通用语言去拆分出问题的解决方案、不同领域问题，然后透过不同的Bounded Context边界来管理团队、分析与建模，如此一来，就会产生属于自己的领域模型，透过这些领域模型撰写可用于生产或正式环境的程式码，以及测试环境的程式码，再透过测试程式码验证生产环境程式码有无问题，过程中并以领域模型同时指导生产与测试环境的程式码，然后在重开发过程中，重新提炼出经进化完成的通用语言，再从这个通用语言结合新的需求、新的商业目标、问题再拆分出可能要面对的新的Bounded Context边界。并成为一个反复循环过程，“我认为这才是在做架构设计应该要有的流程与方法。”