前言

今天下午公司同事内部分享了UML和领域驱动的知识，由于之前接触过这块知识，所以也没产生醍醐灌顶的感觉。有时候虽然听着都似曾相识，但要表达出来还是需要一定积累的。分享后听众都发表了自己的言论，这也同时引发了我的思考。

什么是架构

这个问题初期我是不好回答的，因为我问我自己这个问题时，脑袋短路了。这时候我只能从原始需求出发，回想整个软件开发历程。就拿近期做的一个数据对接流程举例吧！

项目背景：其他项目组为A国外客户定制过购票流程，但我之前并不了解。本期需求是需要将购票相关数据推送到A客户。

第一版接到的需求是客户方粗略的提供了一些接口，但客户方和我方字段映射不明。需求到我手里，我是一片茫然。经过和同事一番互相辩论，总结出需要客户提供整体流程，什么时候推，推哪些数据接口。

N个月后客户回复了对接流程，接口API。因为是国外客户和时区问题，聚齐双方进行电话会议是个相当麻烦的事。两次电话会议后，字段映射终于确定下来，其他流程也沟通清楚。经过苦逼的一天加班加点开发后，初步完成API数据对接。国外客户也开通了微信，再配合邮件，总算建立了一个沟通渠道。

这里有没有架构？我也说不清，应该是没有。这是其实最重要并不是代码，而且建立一个合适的沟通渠道，一个合适的接口推送流程。

至于到了实现部分需要注意的就是执行接口推送的部分记录下请求和返回日志，便于排查问题。条理清晰，缩进规范，注释明确，测试正确，即是很好的完整功能了。即便是这些需求清晰后的代码，我也是重构了两三遍才得以看着舒服些。

再往大了说，需要日志的地方应该支持统一的AOP切面。AOP算不算架构？

业务多了以后，为了方便单元测试一般要支持DI依赖注入，会引入Autofac等，autofac算不算架构？

有时候跨系统rest传输时为了解藕model，会建立对应的DTO，需要用到Automap开处理字段映射，所以automapper算不算架构？

还有所谓的三层架构，MVC，领悟驱动设计，日渐兴盛的微服务等等……到底什么是架构？

跳出软件

当我们为概念而头痛的时候，不妨跳出软件这个范围，去看看公司是怎么运行的。能运行稳健的公司应该是有一个可行的架构支撑的。

以目前互联网公司职能划分，一般有技术，产品，设计，人事，运营，销售，后勤等诸多部门协理合作，共同维护公司的发展。也有以产品线划分，每个产品线自成一组。

如果这个公司正常运行，我们可视为基于一个良好的组织架构。

架构无处不在

基于上面得出的结论，我们可认为只要代码能运行起来正确执行需求，就可认为它采用了一个架构。所以架构无处不在。所以才有无数牛人总结了各种各样的架构思想。以代码工具展示出来就成了autofac,automapper等。