作为一个架构师和部门及产品的技术负责人，当我第一次接触到DDD（领域驱动设计）的时候。我为这本书所展现的思想深深的触动。长期以来，我总认为自己是一个孤独的舞者，对软件架构曲高和寡。但现在是改变的时候了。在产品线的开发中、我不能再做一个孤独的开发者。
首先对于领域专家，以前我有一些抵触和轻视。我向他们讲述的是软件的专业名词，以软件专业开发者而不是客户的立场上去开发。做电子支付时、一位资深业务经理给我讲述“授信业务”-这个专业很强的词汇。我听到这个词的第一感受：准备授信贷款的客户的所有牵涉到公司注册、法人、销售额、信用记录等的信息。我在劝说他们：你们能否改变称谓：客户基本信息-贷款。我的想法：对于整个大系统的会员都需要一个包络万象的客户基本信息，它有以下方面：1：基本-邮箱、手机、姓名（会员名）、会员ID。2：商业：订单的发货地址、收货地址、经营业务、客户类型、交易金额、交易信用等级等。3：贷款-贷款信用等级、一定时期内的销售额、法人信用记录、可质押物等。这些对我来说是战略层面上的东西，你的授信业务只是我的一个方面。但对于这个领域专家（授信业务领域专家）来说：这实际上是他的全部。在互相坚持己见的合作中、软件也被开发出来了。但显然我们彼此都是孤独的。我轻视领域、他们轻视软件设计。没有找到结合点。在这本书中讨论了建立一套适用于领域和设计的通用建模语言，大家弱化自己的专业性而求同存疑。通过这个总线（BUS）结构、把需求传达给我，我把实现结果传达给你。用的越好越减少分歧。
其次、由于新兴的互联网电商的触角已深入到互联网金融行业。而这些我们并不熟悉、对行业的复杂性没有稳定的认识。对能能实现的User Story没有太准确的概念。有时还停留在CRUD层面上。我们对领域专家的建议往往领会不深，这中间也走了一些弯路。适时适度的引进领域专家是解决这些问题的不可或缺的第一步，而建立好表现业务流程（侧重）和技术（主要是必要用例）的通用建模语言（通用仅限于团队内通用、只为交流）才是关键。
最后、对技术的具体实现，不是通用建模语言的内容。即通用建模语言用于解决业务流的技术实现。对于框架的实现的优劣，需要来自不同领域的专家来测试它。这是产品线战略，项目经理、高级程序员做不出来，也无法检验。各个领域专家能促使其完善。
而这些内容在深刻领会【领域驱动设计】的基础上，都相应的迎刃而解。本书从需求分析、详细设计、软件代码做成等各个方面探讨了【领域驱动设计】对加快开发进度、保障代码扩张性、设计规范、代码安全等各个方面有了详尽的阐述。是一本难得的好书。
阅读(2107) | 评论(0) | 转发(0) |
