Daniel Hu的技术生活博客

2009年4月加入公司以后做的第一个项目是给公司的事业部A做个类似Google Calendar的时间、任务管理平台，使事业部A能够在这个平台上开展一项具体的业务，并加以管理和统计。所以公共Calendar服务差别最大的一点是我们的Calendar需要实现对事业部A或者未来其他事业部的“应需而变”。当时做第一版设计的时候就提出了“抽象出一个通用的任务制定、整理、展现的平台。这个平台可以方面的加以扩展以满足多种业务对任务管理的需求”这样一个目标，可在经过之后的若干次的业务和功能的扩展以后，我发现这个产品离产品化和平台化越来越远，直到最后成为了事业部A的专属产品。最近的一段时间内对这个产品如果实现产品化和平台化做了进一步的思考，这篇文章就是这些思考的汇总。

2009年4月的第一版设计——基础设计的失败

当时在设计的时候，有两个设计重点。其中一个是“任务”这个概念，当时主要的精力放在了对任务的抽象上，所以针对任务这个对象设计了开始时间、结束时间、重要度、标题，还包括了任务的创建、完成、推迟等行为。当时考虑如果通用的任务概念无法满足某个事业部的需求时就为这个事业部定制“任务”这个概念，这种设计的具体表现体现在当时设计了一张Task表并预留了许多字段，并且自欺欺人地认为这些字段能够支持未来业务平台的扩展。

剩下的另一个设计重点是如何为这个业务部门定制Calendar的展现样式。业务部门的需求是要根据这个事业部的需求定制一个Calendar的每日单元格。当时对Calendar控件提出了“能够支持日历、月历、周历等多种操作模式的变换以取得类似Outlook中日历功能的效果”，“Calendar容器能够支持多种Widget的Plug in。有需要使用Calendar功能的业务可以根据自身业务需求定制Widget，并能方便地跟Calendar容器整合在一起。”。Calendar控件在之后得到了基本的实现，但应需而变的Widget方案并没有能够实现。

当时就是带着这两个巨大的问号，我们完成了这个功能的第一版。

2009年12月的第三版功能升级——平台化的终结

2009年12月还是这个事业部提出了很多“管理”方面的需求，这些需求使得这个事业部成为了这个产品的“惟一”主人。

2010年1月——新的思考

对于一个大型的企业应用需求往往总是来自于某个较小单位，并逐步的扩展到更大的范围，而另一方面软件设计往往力求能最大程度的支持未来业务的扩展，也就是想实现产品化、平台化的目标，当有新的需求需要实现的时候，能够付出最小的成本。这两者之间某种程度上存在着很大的矛盾，要解决这种矛盾，我目前的思考是要依赖以下几点内容

• 分析需求，识别出需求涉及的领域。如果没有对需求进行领域的划分，或者划分是错误的，结果只有一个——产品化和平台化的终结。
• 在领域划分的基础上，规划每个领域的基础、高阶服务。每个领域可能会有若干个层次的服务：基础、高阶。以Calendar领域为例，基础服务可能就有任务的管理（创建、删除），以日历、月历、周历等多种操作模式的变换。高阶的服务可能包括时间冲突的提醒，任务的提醒等等。
• 将具体的需求通过，某个领域的服务，或者多个领域的服务组合来加以实现。组合式的服务基于几个领域的基础服务构成一个新的服务。每个领域的基础服务要力求“最强大化”，否则整个平台的扩展就会受到很大的限制。

还是以那个事业部A的需求为例。

• 我们识别出需求涉及Calendar和A事业部两个领域。
• Calendar领域提供的基础服务包括任务、时间的管理、Calendar页面的展现，高阶服务包括任务提醒等等。A事业部领域包括了具体任务的制定业务、任务执行的监督、任务执行状态在Calendar页面的展现、任务执行的具体内容和后续跟踪等等。
• 通过将Calendar领域的任务管理服务和A事业部领域的具体任务制定服务组合在一起实现A事业部任务安排的需求。将Calendar领域的任务管理服务和A事业部领域的结果反馈服务组合在一起完成A事业部的结果反馈需求。
• 当后续B事业部想要在Calendar平台上开展自己的业务的时候，由于Calendar领域的服务没有夹杂任何其他领域的内容并且实现了功能的最大化能够很有效的被B事业部加以重用。

总结

• 分析需求，识别出需求涉及的领域。对领域间的隔离态度上是“决不妥协的”。
• 每个领域的服务要追求最大化、最强大化。
• 具体的需求通过，某个领域的服务，或者多个领域的服务组合来加以实现。