两年前偶然接触了DDD（领域驱动设计），虽然读过了这方面最重要的两本著作，但是一直没有机会真正实践，在自己做过的业务架构设计项目中曾想做过一次尝试，但最终没能进行下去，究其原因，我想，应该是这种设计不能是“一个人的战斗”吧，需要上下游共同研究。
DDD诞生的时间不短了，但是一直没有很流行，一方面是因其设计方法较为复杂，一般设计人员难以短时间掌握；另一方面，也是一直没有特殊的理由让大家有足够的动力去拥抱这一比较“困难”的方法，直到微服务的兴起，二者的天然契合让DDD被越来越多的大公司重视，比如NETFLIX和阿里。今年终于参加了一次“领域驱动设计中国峰会”，近距离听听实践者的亲身感受，峰会的热烈、外地慕名者的踊跃，充分体现了DDD的上升势头。
DDD是一种从业务架构直通技术架构的设计方式，这也是我当时做业务架构时对这一方法产生兴趣的原因。但是因其在技术设计方面的内容较为深入，所以对多数非技术类的产品经理或者业务架构人员而言，不是很容易掌握。与多数架构设计一样，DDD也不是一个会产生“统一结果”的设计方式，尽管有统一的术语，并把在业务和技术、技术和技术之间建立“统一语言”作为目标，但是作为一种有较强开放性的智力活动，设计总是很难产生如同数学般的定理，同一方法在不同人手中会产生不同结果。一位嘉宾在分享中回答我的问题时，也坦言，当他们决定采用DDD时，仅就基本设计理念，在架构师团队中就花了三个多月时间才形成接近一致的看法，而后在实施中又是通过每一轮迭代不断与开发团队磨合，直到大家逐渐对方法和设计都达成一致的认知。正如多位嘉宾提到的，包括业务架构在内的架构设计，都不可能一蹴而就，必须反复沟通、修正，直到形成共识为止。
今年有多场演讲都涉及业务架构这个主题，并有一场是业务架构专场，我特别去感受了下在这种大型会议上难得一见的同行，她讲了从业务架构的“画布分析法”到DDD的过渡方法。“画布分析法”跟我之前用过的“战略房子”非常接近，应该说只是没有“战略”这个屋顶部分，其他内容完全一致。能够有这样一个专场，可见DDD方法体系对业务部分的重视，的确，没有一个好的业务架构，也很难有一套的好的业务系统。如同一位嘉宾开的玩笑一样，业务说要风险管理系统，技术立马搬出Hadoop、Hive等杀器，业务说打住，我要的只是黑名单。
好多技术人员觉得战略是一个比较空、离自己很远的东西，其实不然，战略必须落实到业务中，没有落实到业务流程中的战略是不可落地、不会被真正执行的，而落到流程中的，自然就会再考虑落到系统中。如果技术人员，尤其是架构师，对公司战略不了解，那怎么判断自己设计的系统是符合业务发展要求的呢？如果只是听业务人员要什么给什么，那这种N次传手后衰减了无数的信息，是否能开发出一个真有业务价值的系统呢？没有对公司战略、业务架构的共识，就不可能产生跟公司整体行为配套的业务系统。现在是提倡业务与技术深度融合的时代，如果不像DDD方法那样，业务人员、领域专家、架构师、技术人员坐在一起达成共识，而靠“铁路警察、各管一段”的方式传递需求，产生的必然是“破债缠身”的系统。而更进一步的，技术人员要主动走到业务人员中间去开展交流、获取需求、解决问题，业务架构这个技术堆儿里偏业务的品种，应该多绽放一些生命力。争取把业务人员甚至你的老板都培养出架构思维，公司才能在真正把IT跟业务融合起来，不妨再想想《凤凰项目》吧。
希望DDD方法能够带动业务架构再来上一波。
