粗略的把我接触过的系统分成几种类型，数据处理型、技术型、网站应用型。
数据处理型范指绝大部分的企业应用，例如ERP、MES、SCM、CRM、HR等等，这类系统的主要任务就是处理各种单据/数据的流转、运算，完成各种事务性任务。
这类系统的核心价值在于对领域业务的掌握和消化，所以架构的重点是对特定领域业务的收集、分析、设计。这类系统的开发不需要多少技术含量，门槛在于对业务是否掌握，有没有推广销售、实施的能力。
技术型泛指业务含量不多，重点是使用某些技术，实现一些难度高、处理复杂的任务。
这类系统的核心价值在于使用的技术或者设计思想，这些技术和设计思想的运用，很可能是其他人无法复制、超越的，所以架构的重点是对特定技术或设计思想的掌握、运用。这类系统通常体现为基础组件平台、工具型的应用，例如ORM框架、流程管理引擎、CMS系统、BI产品、数据库等各种开发工具等等。
现在是互联网时代，还有一种就是大量的网站应用。当然，HR产品可能是BS结构的，但并不能把它归入网站应用，它是用于解决企业内部事务。CMS系统、BI产品等也可能是BS结构，但它们的重点职责是一种工具型系统，用来生成、架设网站，构建报表、决策分析中心。
网站应用的核心竞争力是创意和推广，加上一定的用户体验效果，技术上的核心是高访问量下的性能解决方案。
不同类型的系统，决定了架构师的工作重点，对架构师的能力要求也有所偏重。
对于想向架构师方向发展，或者架构师自己，需要根据职业发展方向积累知识、培养能力。
对于企业招聘，需要根据自己的业务范围和岗位职责有重点地考核应聘者。
假若我现在需要开发一个ERP，老板丢给我一个很牛的架构师，他知道C#每一个指令如何执行，23种设计模式运用的滚瓜烂熟，我还是可能会很头痛，因为不少偏重于技术的强人，对业务有一种天生的抵制情绪。就如同程序员自然而然就想否定自己写的东西里存在某个bug，尤其是对于那些难以重现的，第一冲动就是要跟tester干上一场，而不是一起合作分析可能的原因和解决方法。
如果公司要开发一个ERP，各个领导、专家提出了很多的构想，这些构想太神奇了，足以吸引大部分客户的眼球，但从技术员的角度看，都是非常的有难度。这种情况下，如果架构师绝大部分的时间都在思考技术框架的方案、设计模式的运用等偏重于技术层面的事情，那这个项目是否成功就得打上很多个问号了。因为其一，ERP覆盖了太多复杂的业务需要架构师梳理分析设计，技术是次要的。其二，架构的灵活性并不等同于技术的先进、模式运用的多少，特别是在这种数据处理型的系统中。
数据处理型系统，需要架构师、开发团队对特定的领域知识拥有浓厚的兴趣和认知感，具备、不断地积累领域知识，向领域专家的方向发展，乐于接受领域业务上疑难、繁杂问题的挑战，不懈的在领域建模、领域模型的完善上思考、研究。
如果公司要开发一个数据库产品，架构师却主张来个领域驱动方式开发，投入大量的时间进行涉众需求调查、分析，模型的建立，那这个项目是否成功也得打上很多个问号。因为技术型的系统基本都是以比较封闭的方式开发出来，就是大家所说的闭门造车，产品的使用性完全取决于建造者的理解与把握。这类系统关键是核心技术、架构设计思想的突破、验证与运用，架构师和团队需要在这方面投入最大的精力，一次性收录太多的特性，反而会分散架构师的工作重点、团队的人力，使得核心部分作的不完善，最终系统不理想。
技术型系统，对架构师和开发团队技术面的要求相当高，组织也需要为团队提供良好的技术研究、交流气氛和机会，不断地对研究成果进行验证，运用到产品中。
举的例子不一定合适，但足以说明架构重点的重要性。无论是个人还是庞大的组织，都只具备有限的精力，去做有限的事情。哪怕是MS，尽管前面有SQL和Windows那么多版本的积累，在Vista和新版SQL的开发上，预期革命性的features太多，最终发布也是经历波折，并将一些feature留在后续版本中添加。
清晰的认识自己所开发系统的重点在哪里，审视自己以及组织的重点是否在偏离这个方向，是很重要的。而事实上也很容易发生偏移。
领域驱动的设计思想，在数据处理型系统的开发上具有非常好的运用基础，因为数据处理型的系统是业务密集型的，领域驱动的思想就是以领域业务为核心去驱动开发过程中各个阶段的活动。