最近加入新团队，尝试新的项目类型，一段时间一下也感谢颇深，目前也算是深入了解了团队和部分项目，其实平时也经常习惯性的思考团队分工协作这些方面的东西，鉴于目前团队状态和先前已经有明显区别，自然也萌生不同的思考。

　　老实说本人是带着先入为主的想法而来的，一向推崇敏捷，推崇领域驱动设计（下文称DDD），故而也无时不刻向周围的同事渗透这些思想和倾向，特别是目前是从事企业应用方面开发工作，业务导向，尤为适合。

　　针对目前的主要系统（下文以wf称，企业应用）和团队，且听笔者一一分析道来.

　　目前wf团队人员组成，与一般互联网项目相比优势之一就是需求分析师经验丰富，均可算是某一业务领域的专家，比起辛辛苦苦白手起家的web2.0创业型项目来说，我们可说有着无比清晰的系统建设方向，靠谱的需求来源。需求的方向性是明确的，这点对于开发者来说是最好不过了，我们说“靠谱”很重要，企业应用应该不至于让你被需求雷死：）。既然如此，为什么不用好这些资源呢？因为是企业内部，我们总是能和需求方以及业务专家保持直接有效的沟通，他们能够且应该比开发人员更了解业务该如何设计和系统该如何被使用，这便是实施领域驱动设计最为重要的资源和前提，业务是最具有价值的，因而我们希望并且应该做到当业务在系统中被实现时，它是可重用，可理解，可验证的，而不是用一堆晦涩的脚本或者数据库表来描述牵强的描述它。往往我们在和业务专家沟通的时候，他们已经参与或者在帮助我们设计业务，他们期望系统中业务的运行/实现方式是如他们所描述的一致，这对于业务的深入和衍进具有很大的意义，业务在专家的脑子里，若我们的设计映射了这种业务描述，那么也就等于系统/业务设计也就在他们的脑海中。

　　当下，企业信息化阶段已经从早期的企业网站式向企业IT系统化转变，IT系统将对企业发展提供全面支持和对业务的灵活响应，您无法难要求您的开发人员都是业务能手，但是您是否发现原来身边的业务部门人员都是天生的业务专家，如果让他们参与系统设计，让领域专家来支持您的企业信息化建设是不是能让系统更良好的支撑业务要求？

　　Ok，对于以上文字，笔者得出的结论就是：业务是最具有价值的，业务系统应该重视和维持价值而不是断章取义的代码设计。

　　接下来，笔者假设您同意了这个结论，往下看。

　　上文反复提到让业务专家来设计业务和系统，那么如何来具体实施？业务需要描述，同时也需要被实现为可用代码，显然业务专家不认识C#/Java，因而业界提出了所谓DSL这样的领域特定语言作为中间语言来连通业务和系统实现，DSL最近很火热的，感兴趣的具体您可以去了解一下。笔者认为目前这个还是概念，理想化的东西，业界希望定义出诸如工业标准的东西，理智对待即可，取合适而用之，“软件开发没有银弹”，DDD也是一种应对之道而已。

　　回归正题，如何实施。简单而言，我们需要和业务专家一起进行系统的设计，用双方均可理解的方式和语言来描述业务和设计，设计应和分析后达成一致的业务描述可一一映射，业务专家也需要能理解一定程度的传统系统设计思想（比如对象，关联，领域模型等概念），其间可进行领域建模，编写伪代码等来描述领域问题，具体设计对于开发人员有较高的要求，需要具备良好的OOA/OOD能力。

　　实施DDD，很重要的一点，必须尽量真实到达业务和具体设计的真实映射，如果设计和领域模型不能较直观的描述业务，那就失去意义，为保证这点，需要依靠良好的面向对象设计来保证业务映射，对最终设计需要根据确定下来的业务设计描述来验收。

　　从代码层面来讲，需要保证业务可重用性，必须保证领域层完整性，可测试性，以及保证领域业务不外放。往往分层架构会导致有些业务处理出现在不合适的位置，比如向UI层渗透，或领域服务暴露不当等，理想状况应该做到领域层的平台无关性，当然这是理想化，笔者认为领域可测试性，业务可验收性是最为重要的。

　　具体框架支持方面，谈DDD估计必谈ORM，领域层再优雅也需要持久化，一个映射能力优秀的持久化框架是必备的，目前我们使用的是NHibernate，虽然有些地方实在不那么优雅，但它还是非常优秀的。

　　至此算是简单的把领域驱动引入的可行性阐述了一番，看了上述的种种文绉绉的方法之谈是否觉得还是缺少些什么？具体实施层面的有了依据，从项目和团队层面来说，是否需要一个更为有效的管理方式来支撑？需求/业务永远在变化，那么敏捷开发号称拥抱变化，是不是能引入而用之？

　　看一些实际状况片段：

　　需求分析一周，一份完备的需求送入开发，评估之后4周，继而投入4周的漫漫开发中，3周半的时候开始提交测试，上线前一两天，需求方开始体验/验证系统，“这个怎么是这样的啊”，“需求变更了，这个地方要这样”，“明天发布来不及改，下一期吧”，“测试来不及啊，这不是白测了吗”“排到后面…”。4周后发布了，变更被排入开发，接着，回到下一个漫漫的周期…

　　“这个样式怎么乱了？”，“底层接口不稳定，没办法搞”，“这个为什么要这么做，有价值吗”

　　是的，这是瀑布式开发吧，我们的迭代周期是多久，“上次是3周，有次是2周，有次是4周，哦，”。

　　敏捷可以让我们变成怎么样？用Scunm试试看？

　　组建2-3个Scrum团队，3-4人，每组一个Master，ok，开工，初步定义sprint周期为2周，可由一位需求分析师暂代ProductOwner角色，来全程跟进，将项目需求进行分析后，对功能进行合理拆分为backlog，进入迭代，每个sprint结束需交付可用产品/系统功能，交付需求方或测试验收验证，依据情况可让已交付功能上线。休整后进入下一个sprint。依此，磨合一段时候后，确定一个稳定的迭代周期，快速响应需求，定期准时交付可用产出。迭代期间进行每日会议，及时沟通。由于是长期的内部系统，无需对较大项目或复杂需求做详尽估时（预估的几乎不可能准确，准确的代价是拒绝了变化，这是不符合期望的），只需总是按照迭代周期向客户进行交付，稳定的周期对用户进行反馈，我们将欢迎变化，你可以在任何时候提出变更，当然变更总是有代价，提出人心知肚明，而合理评估后欣然接受相信一定是客户期望的态度，稳定的交付周期也会让客户明确感知开发成效，藉此将树立团队形象。