一个困惑的类设计！

首先是一个文档管理类，但是文档管理里面有一些操作是文档版本管理，文档关键字管理的方法，如果全部放在一个类里面，感觉好混乱，很不舒服。所以我现在分开成2个类。每一个类定义一个接口。
然后在文档管理类中，添加创建文档版本管理和文档关键字管理的接口。
请问，我这样做何不合理啊？这个设计，该如何分析和设计这样的类呢？

 public class BaseDoc:IUIProxy

    {

        。。。

        public IDocVerson CreateDocVerson()

        {

            return new DocVerson();

        }

        public IDocKeyword CreateKeyword()

        {

            return new Keyword();

        }

        #endregion

    }

------解决方案--------------------
提示你一下： 文档和文档的版本是1对多的关系，文档关键字与文档间是多对多的关系.
------解决方案--------------------
晕！实在是不知道你在干什么。

首先，动不动就“xxx管理”这是笔杆子写企业宣传材料忽悠客户的啊！之后总要具体化到产品特性上的。那么管理是什么内涵、什么具体流程，总要具体化的。通常来说“管理”是你许许多多产品的综合，甚至你写了1000个对象类也还没有整理出“管理”，你不能把“管理”作为一个程序里边的一个对象类啊。

其次，怎么能动不动就把一个动词建立为一个类型呢。面向对象设计，当然也还是要尽可能少创建类型啊。就好象编程的时候当然也要尽可能少写代码啊。脱离开主语，那么干巴巴的东西就是灵魂的空话。所以都是首先研究名词概念，研究它们如何归类和扩展，而活动、状态等都是围绕着它们展开的。

也就是说，建立类型是要回答“文档是什么、版本是什么、关键字是什么，它们之间的关系怎样”，然后放到各种典型操作场景、用例、活动、状态转移模型、规划模型、计算模型、控制流模型、操作系统环境、外设环境等等中去反观这个类型关联模型是否比较合适。

如果你见到一种操作需求，就叫做一个类型，那么你的设计也就没有什么复用性。因为操作需求是随时变化、无穷无尽的。正是因为所谓的函数分解、功能分解，这种只见功能调用而不顾概念的独立和扩展的思考方法方法带来了盲目的东西，所以才会有面向对象软件工程的出现。
------解决方案--------------------
脱离开主语，那么干巴巴的东西就是灵魂的空话  -->  脱离开主语，那么干巴巴的动词就是无灵魂的空话
------解决方案--------------------
楼主用"管理"这个词非常好,但我希望它是个动词,而不是名词,这时时刻刻提醒设计者关注业务处理,而不是文档有哪些字段,
我临时写一段代码,不一定合适你,仅供参考

public interface IDocVerManage{

    Method CreateVersion{get;set;};//我这是MVC的写法,你也可以void CreateVersion()

    //其他业务声明依此类推

    }

public interface IDocKeyManage