14 个解决方案
#1
建议你通过学习一下uml来规划你的模块.
#2
模块功能独立性，高内聚，低耦合，这个我知道。UML中Components我会用里面的表示来画图。
我想制定划分模块的规则。就象写程序时用的命名规则一样。
比如：现在要做一个MIS，使用的是C/S结构，可以划分成业务对象，业务流程管理，为务分析统计等几个模块。
这里划分的依据，划分的标准是什么？
我想要的是划分模块的规则？
我想制定划分模块的规则。就象写程序时用的命名规则一样。
比如：现在要做一个MIS，使用的是C/S结构，可以划分成业务对象，业务流程管理，为务分析统计等几个模块。
这里划分的依据，划分的标准是什么？
我想要的是划分模块的规则？
#3
业务操作需求
#4
如果是只针对具体的业务我就不用考虑规则问题了。
现在就是要跳出具体的业务，站在更高的层次来考虑模块的划分问题。
因为具体的划分不是自己做，所以要定一些通用的，大家都可以执行的划分规则。
现在就是要跳出具体的业务，站在更高的层次来考虑模块的划分问题。
因为具体的划分不是自己做，所以要定一些通用的，大家都可以执行的划分规则。
#5
可能大家都保密吧！
#6
设计很复杂，要考虑很多因素，最后要找到一个最优的方案，我认为如果想找一种规则，不同的人应用这个规则对相同的问题都可以得到相同的结果，而且规则还容易学习和操作，这样的规则是找不到的。即使强行制定某种规则，应用这些规则做出来的设计不说是无法做到最优，连可行可能都做不到。这是我的直觉，因为设计太复杂了。
如果这些规则存在，就不需要人去设计了，让机器帮你设计就好了。
有种东西和这种规则相近的，就是模式，每个模式都是一个局部设计，包含了模块的划分，只要应用条件适合，要解决的问题相匹配，就可以套用模式的设计，也就得到模块划分。
但有一点很不同的，模式是不完整的，规则一般需要完整，也就是对任何一个问题，都应该可以应用某个规则解决。而模式则没有这种完整性，只能解决少数的重要的问题，大部分问题都没有成熟的模式可以应用，至少目前这样。如果有一天模式完整了，有了一本万能模式手册，那么这个手册就是楼主需要的规则。
如果这些规则存在，就不需要人去设计了，让机器帮你设计就好了。
有种东西和这种规则相近的，就是模式，每个模式都是一个局部设计，包含了模块的划分，只要应用条件适合，要解决的问题相匹配，就可以套用模式的设计，也就得到模块划分。
但有一点很不同的，模式是不完整的，规则一般需要完整，也就是对任何一个问题，都应该可以应用某个规则解决。而模式则没有这种完整性，只能解决少数的重要的问题，大部分问题都没有成熟的模式可以应用，至少目前这样。如果有一天模式完整了，有了一本万能模式手册，那么这个手册就是楼主需要的规则。
#7
在建系统架构时可以引用其它模式，在设计某些构件时也可借用其它模式,这不错，但这不是我想要的。
我在这里所说的规则可以说是一种标准，一个协议，大家在设计某些类，增加某些文件，可以结合到规则以决定其所属的模块。
比如我现在要实现一个权限管理的功能，而在实现这个功能可能要用到用户、权限、角色等几个类，我可以把这些类独立放在一个叫权限管理的模块中。现在我要增加单位、部门类，这两个类在权限管理的功能里用到，在业务流程管理功能中也会用到，我应把这两个类放在哪个功能模块中？还是独立放在一个模块中？
（我现在的做法是把单位、部门类这两个类放在权限管理的功能模块中，因为我可以比较容易使用。）
如果没有一定的规则，叫别人如何遵循自己的系统架构模式？因为不是每一个类都由自己设计的。
我在这里所说的规则可以说是一种标准，一个协议，大家在设计某些类，增加某些文件，可以结合到规则以决定其所属的模块。
比如我现在要实现一个权限管理的功能，而在实现这个功能可能要用到用户、权限、角色等几个类，我可以把这些类独立放在一个叫权限管理的模块中。现在我要增加单位、部门类，这两个类在权限管理的功能里用到，在业务流程管理功能中也会用到，我应把这两个类放在哪个功能模块中？还是独立放在一个模块中？
（我现在的做法是把单位、部门类这两个类放在权限管理的功能模块中，因为我可以比较容易使用。）
如果没有一定的规则，叫别人如何遵循自己的系统架构模式？因为不是每一个类都由自己设计的。
#8
gephen(革风)
你的想法是不现实的。不过这还不是问题的全部。
面向对象的设计最基本的要素就是基于对象的设计，而你的模块的概念只是基于功能的。这是面向过程设计的遗留思维方式。
同时有几个人都设计了用户这个类，这样的事情即使发生也可以利用refactor解决。关键为什么会大家都去设计的用户这个类，这是你项目中的组织功能出来问题，说明交流不够。
如果你一定要那么一个原则，我也可以给你一个。那就是把类作为模块，一个类就是一个模块。这也是我最概要设计的对自己的粒度要求。
你的想法是不现实的。不过这还不是问题的全部。
面向对象的设计最基本的要素就是基于对象的设计，而你的模块的概念只是基于功能的。这是面向过程设计的遗留思维方式。
同时有几个人都设计了用户这个类，这样的事情即使发生也可以利用refactor解决。关键为什么会大家都去设计的用户这个类，这是你项目中的组织功能出来问题，说明交流不够。
如果你一定要那么一个原则，我也可以给你一个。那就是把类作为模块，一个类就是一个模块。这也是我最概要设计的对自己的粒度要求。
#9
现在我的做法是把一个构件作为一个模块，而不是用一个类是一个模块的形式。我把实现相关的类，资源文件，划分为一个个构件，然后把这些构件集成系统。不过这些构件不是具有泛重用性的，只针对一个应用领域，代码只用一种编程语言实现的。这样做的结果是增加了交流与协调的时间。
难道真的没有一定的规则可以遵遁，以减少开会的时间，降低协调的难度？
难道真的没有一定的规则可以遵遁，以减少开会的时间，降低协调的难度？
#10
对一个系统的划分我的做法是这样的:
我的划分的根据是系统的功能实现.如果该系统较大,我先将之划分几个子系统,然后在子系统中划分出一些模块.
如我现在做的一个项目我就将之分为检测站子系统、收费站子系统、管理控制台子系统和移动办公子系统。我做的是基于C/S结构的，这些子系统直接访问中心数据库，通过数据库相互交流信息。
像收费站子系统，我又按功能划分为：收费工作台模块、本地收费工作台模块以及数据上传模块。根据功能实现的需要可将模块进一步划分成子模块。
这是我的一点开发感受，没有遵循软件工程的思想，请大家多指教。
我的划分的根据是系统的功能实现.如果该系统较大,我先将之划分几个子系统,然后在子系统中划分出一些模块.
如我现在做的一个项目我就将之分为检测站子系统、收费站子系统、管理控制台子系统和移动办公子系统。我做的是基于C/S结构的，这些子系统直接访问中心数据库，通过数据库相互交流信息。
像收费站子系统，我又按功能划分为：收费工作台模块、本地收费工作台模块以及数据上传模块。根据功能实现的需要可将模块进一步划分成子模块。
这是我的一点开发感受，没有遵循软件工程的思想，请大家多指教。
#11
你把一些类组织在一起当作一个模块，但这种结构是否稳定呢？万一有一天发现这种组织方式不合理，需要改动，那你怎么办。其实呢，只有类才是最稳定的原子结构，而你所说的相当于分子结构，至于要做到哪个结构，要看你研究的是物理问题还是化学问题。我赞同o6z的说法，概要设计要到类的粒度，即便是研究化学问题，心里也应该清楚最基本的结构是原子。
说到权限管理，我就再罗嗦几句。
出于易用的原因，把单位和部门类这两个类放在权限管理系统中，这是允许的，但如果你的系统涉及人事管理，单位和部门与人事系统的联系要比与权限管理系统的联系强得多，把它们放在人事系统应该更合理，更高内聚。
实际上，权限系统与单位和部门类的联系不强的，用户的权限可以由其登录时“映射”到角色来实现，之后，权限就由这个角色来决定，单位和部门只在登录时与权限系统发生联系，之后就与权限系统无关（当然不是绝对）。这是设计方面的问题，是否需要这么复杂的设计来解耦，根据需要而定。
说到权限管理，我就再罗嗦几句。
出于易用的原因，把单位和部门类这两个类放在权限管理系统中，这是允许的，但如果你的系统涉及人事管理，单位和部门与人事系统的联系要比与权限管理系统的联系强得多，把它们放在人事系统应该更合理，更高内聚。
实际上，权限系统与单位和部门类的联系不强的，用户的权限可以由其登录时“映射”到角色来实现，之后，权限就由这个角色来决定，单位和部门只在登录时与权限系统发生联系，之后就与权限系统无关（当然不是绝对）。这是设计方面的问题，是否需要这么复杂的设计来解耦，根据需要而定。
#12
我想楼主可能低估了设计的复杂程度，模块的划分是设计的一个关键部分。首先设计的目标本身就复杂，首先要尽量实现客户提出的要求，还要可以接受的运行效率，还有设法将低成本，还要为维护考虑，可理解性可扩展性可重用性等等；这些目标之间还有权重的问题。除了目标之外，还有设计的输入和约束条件，比如可以选择那些不同的算法、在哪个平台上实现，是不是要重用以前写的代码或者购买第三方的类库等等。在设计中只有上面提到的一个方面的看法不一样，最后设计结果就会差别很大。
如果想解决沟通效率的问题，也不是很难，通常的做法是让一个人来划分模块，确定模块的接口，其他人则检查这个设计是不是有严重问题。如果设计是集体完成的，效率就比较低。
如果是考虑那些类属于那些模块，这个是组织的问题，组织的好的确比较容易查找需要的类。我一般用聚合关系作为线索组织复杂的设计，比如设计了一个权限管理器对象，为用户提供权限管理功能，这个权限管理器聚合了用户类、角色类、权限类的实例，则权限管理器对象可以作为一个模块，而用户类、角色类、权限类属于这个模块。
同一个领域的概念对应的对象，不应该聚合到不同的对象中，比如如果还有一个用户管理器的话，不能让用户管理器和权限管理器同时聚合用户类对象，只能一个聚合一个关联。
只有在不同领域（不同的抽象层次的概念）的概念，比如权限管理器和链表，这两个概念属于不同领域，链表概念更抽象，重用范围更大，可以作为底层的类，聚合到不同的具体领域概念中，而且做好经过派生之后再聚合。
另外不同抽象层次的概念对应的类，不能使用双向的关系，比如双相关联，双向依赖等等，只能让具体的概念看见抽象的概念，抽象概念类不能看见具体概念类。另外单向关系，只能使用继承关系和单向依赖关系，而一般不应该使用关联关系和聚合关系。
一般我使用这些原则来组织类之间关系，效果还比较好。
如果想解决沟通效率的问题，也不是很难，通常的做法是让一个人来划分模块，确定模块的接口，其他人则检查这个设计是不是有严重问题。如果设计是集体完成的，效率就比较低。
如果是考虑那些类属于那些模块，这个是组织的问题，组织的好的确比较容易查找需要的类。我一般用聚合关系作为线索组织复杂的设计，比如设计了一个权限管理器对象，为用户提供权限管理功能，这个权限管理器聚合了用户类、角色类、权限类的实例，则权限管理器对象可以作为一个模块，而用户类、角色类、权限类属于这个模块。
同一个领域的概念对应的对象，不应该聚合到不同的对象中，比如如果还有一个用户管理器的话，不能让用户管理器和权限管理器同时聚合用户类对象，只能一个聚合一个关联。
只有在不同领域（不同的抽象层次的概念）的概念，比如权限管理器和链表，这两个概念属于不同领域，链表概念更抽象，重用范围更大，可以作为底层的类，聚合到不同的具体领域概念中，而且做好经过派生之后再聚合。
另外不同抽象层次的概念对应的类，不能使用双向的关系，比如双相关联，双向依赖等等，只能让具体的概念看见抽象的概念，抽象概念类不能看见具体概念类。另外单向关系，只能使用继承关系和单向依赖关系，而一般不应该使用关联关系和聚合关系。
一般我使用这些原则来组织类之间关系，效果还比较好。
#13
我以前面对的业务比较多的单位，主要的部门有四个，其它有七个，部门下分小队，总共二十一个。要把所部门，小队的管理过程中涉及的对象，以及这些对象的日常处理，到月末，年末的统计分析报表，都一一处理好，要把所有数据整合好，还要应客户对处理流程，甚至小队，部门的变动，如果去到类的粒度并不现实。现在改得最多的是涉及流程、数据对象的类，报表，相反大的系统框架改动很少。
设计一些抽象类以减少改动，这方面的工作也做了不少。
现在要进行一个新的项目，系统框架和模块的设计应是重要的一步。以前这方面的设计是全部设计人员都参与的，花了几个月的时间，总体没有问题，但细节设计得不好，原因很多这里不提。现在分开设计，每人负责一部分，但要定个大家可遵守的规则，以便讨论审核。大家有何想法？
设计一些抽象类以减少改动，这方面的工作也做了不少。
现在要进行一个新的项目，系统框架和模块的设计应是重要的一步。以前这方面的设计是全部设计人员都参与的，花了几个月的时间，总体没有问题，但细节设计得不好，原因很多这里不提。现在分开设计，每人负责一部分，但要定个大家可遵守的规则，以便讨论审核。大家有何想法？
#14
细节部分分开设计有时候也不可避免，每个人都设计完之后一起讨论接口，就可以避免模块交互的错误。
制定成文的规则很难，不过没有规则也不一定就不能统一风格，比如有设计模式可参考的就参考设计模式，每次讨论接口设计的时候可以研究那个接口设计的比较好（而不是讨论是否可行，可行的方案很多），这样久了每个人之间就会有默契，其实就是不成文的规则。
制定成文的规则很难，不过没有规则也不一定就不能统一风格，比如有设计模式可参考的就参考设计模式，每次讨论接口设计的时候可以研究那个接口设计的比较好（而不是讨论是否可行，可行的方案很多），这样久了每个人之间就会有默契，其实就是不成文的规则。
#1
建议你通过学习一下uml来规划你的模块.
#2
模块功能独立性，高内聚，低耦合，这个我知道。UML中Components我会用里面的表示来画图。
我想制定划分模块的规则。就象写程序时用的命名规则一样。
比如：现在要做一个MIS，使用的是C/S结构，可以划分成业务对象，业务流程管理，为务分析统计等几个模块。
这里划分的依据，划分的标准是什么？
我想要的是划分模块的规则？
我想制定划分模块的规则。就象写程序时用的命名规则一样。
比如：现在要做一个MIS，使用的是C/S结构，可以划分成业务对象，业务流程管理，为务分析统计等几个模块。
这里划分的依据，划分的标准是什么？
我想要的是划分模块的规则？
#3
业务操作需求
#4
如果是只针对具体的业务我就不用考虑规则问题了。
现在就是要跳出具体的业务，站在更高的层次来考虑模块的划分问题。
因为具体的划分不是自己做，所以要定一些通用的，大家都可以执行的划分规则。
现在就是要跳出具体的业务，站在更高的层次来考虑模块的划分问题。
因为具体的划分不是自己做，所以要定一些通用的，大家都可以执行的划分规则。
#5
可能大家都保密吧！
#6
设计很复杂，要考虑很多因素，最后要找到一个最优的方案，我认为如果想找一种规则，不同的人应用这个规则对相同的问题都可以得到相同的结果，而且规则还容易学习和操作，这样的规则是找不到的。即使强行制定某种规则，应用这些规则做出来的设计不说是无法做到最优，连可行可能都做不到。这是我的直觉，因为设计太复杂了。
如果这些规则存在，就不需要人去设计了，让机器帮你设计就好了。
有种东西和这种规则相近的，就是模式，每个模式都是一个局部设计，包含了模块的划分，只要应用条件适合，要解决的问题相匹配，就可以套用模式的设计，也就得到模块划分。
但有一点很不同的，模式是不完整的，规则一般需要完整，也就是对任何一个问题，都应该可以应用某个规则解决。而模式则没有这种完整性，只能解决少数的重要的问题，大部分问题都没有成熟的模式可以应用，至少目前这样。如果有一天模式完整了，有了一本万能模式手册，那么这个手册就是楼主需要的规则。
如果这些规则存在，就不需要人去设计了，让机器帮你设计就好了。
有种东西和这种规则相近的，就是模式，每个模式都是一个局部设计，包含了模块的划分，只要应用条件适合，要解决的问题相匹配，就可以套用模式的设计，也就得到模块划分。
但有一点很不同的，模式是不完整的，规则一般需要完整，也就是对任何一个问题，都应该可以应用某个规则解决。而模式则没有这种完整性，只能解决少数的重要的问题，大部分问题都没有成熟的模式可以应用，至少目前这样。如果有一天模式完整了，有了一本万能模式手册，那么这个手册就是楼主需要的规则。
#7
在建系统架构时可以引用其它模式，在设计某些构件时也可借用其它模式,这不错，但这不是我想要的。
我在这里所说的规则可以说是一种标准，一个协议，大家在设计某些类，增加某些文件，可以结合到规则以决定其所属的模块。
比如我现在要实现一个权限管理的功能，而在实现这个功能可能要用到用户、权限、角色等几个类，我可以把这些类独立放在一个叫权限管理的模块中。现在我要增加单位、部门类，这两个类在权限管理的功能里用到，在业务流程管理功能中也会用到，我应把这两个类放在哪个功能模块中？还是独立放在一个模块中？
（我现在的做法是把单位、部门类这两个类放在权限管理的功能模块中，因为我可以比较容易使用。）
如果没有一定的规则，叫别人如何遵循自己的系统架构模式？因为不是每一个类都由自己设计的。
我在这里所说的规则可以说是一种标准，一个协议，大家在设计某些类，增加某些文件，可以结合到规则以决定其所属的模块。
比如我现在要实现一个权限管理的功能，而在实现这个功能可能要用到用户、权限、角色等几个类，我可以把这些类独立放在一个叫权限管理的模块中。现在我要增加单位、部门类，这两个类在权限管理的功能里用到，在业务流程管理功能中也会用到，我应把这两个类放在哪个功能模块中？还是独立放在一个模块中？
（我现在的做法是把单位、部门类这两个类放在权限管理的功能模块中，因为我可以比较容易使用。）
如果没有一定的规则，叫别人如何遵循自己的系统架构模式？因为不是每一个类都由自己设计的。
#8
gephen(革风)
你的想法是不现实的。不过这还不是问题的全部。
面向对象的设计最基本的要素就是基于对象的设计，而你的模块的概念只是基于功能的。这是面向过程设计的遗留思维方式。
同时有几个人都设计了用户这个类，这样的事情即使发生也可以利用refactor解决。关键为什么会大家都去设计的用户这个类，这是你项目中的组织功能出来问题，说明交流不够。
如果你一定要那么一个原则，我也可以给你一个。那就是把类作为模块，一个类就是一个模块。这也是我最概要设计的对自己的粒度要求。
你的想法是不现实的。不过这还不是问题的全部。
面向对象的设计最基本的要素就是基于对象的设计，而你的模块的概念只是基于功能的。这是面向过程设计的遗留思维方式。
同时有几个人都设计了用户这个类，这样的事情即使发生也可以利用refactor解决。关键为什么会大家都去设计的用户这个类，这是你项目中的组织功能出来问题，说明交流不够。
如果你一定要那么一个原则，我也可以给你一个。那就是把类作为模块，一个类就是一个模块。这也是我最概要设计的对自己的粒度要求。
#9
现在我的做法是把一个构件作为一个模块，而不是用一个类是一个模块的形式。我把实现相关的类，资源文件，划分为一个个构件，然后把这些构件集成系统。不过这些构件不是具有泛重用性的，只针对一个应用领域，代码只用一种编程语言实现的。这样做的结果是增加了交流与协调的时间。
难道真的没有一定的规则可以遵遁，以减少开会的时间，降低协调的难度？
难道真的没有一定的规则可以遵遁，以减少开会的时间，降低协调的难度？
#10
对一个系统的划分我的做法是这样的:
我的划分的根据是系统的功能实现.如果该系统较大,我先将之划分几个子系统,然后在子系统中划分出一些模块.
如我现在做的一个项目我就将之分为检测站子系统、收费站子系统、管理控制台子系统和移动办公子系统。我做的是基于C/S结构的，这些子系统直接访问中心数据库，通过数据库相互交流信息。
像收费站子系统，我又按功能划分为：收费工作台模块、本地收费工作台模块以及数据上传模块。根据功能实现的需要可将模块进一步划分成子模块。
这是我的一点开发感受，没有遵循软件工程的思想，请大家多指教。
我的划分的根据是系统的功能实现.如果该系统较大,我先将之划分几个子系统,然后在子系统中划分出一些模块.
如我现在做的一个项目我就将之分为检测站子系统、收费站子系统、管理控制台子系统和移动办公子系统。我做的是基于C/S结构的，这些子系统直接访问中心数据库，通过数据库相互交流信息。
像收费站子系统，我又按功能划分为：收费工作台模块、本地收费工作台模块以及数据上传模块。根据功能实现的需要可将模块进一步划分成子模块。
这是我的一点开发感受，没有遵循软件工程的思想，请大家多指教。
#11
你把一些类组织在一起当作一个模块，但这种结构是否稳定呢？万一有一天发现这种组织方式不合理，需要改动，那你怎么办。其实呢，只有类才是最稳定的原子结构，而你所说的相当于分子结构，至于要做到哪个结构，要看你研究的是物理问题还是化学问题。我赞同o6z的说法，概要设计要到类的粒度，即便是研究化学问题，心里也应该清楚最基本的结构是原子。
说到权限管理，我就再罗嗦几句。
出于易用的原因，把单位和部门类这两个类放在权限管理系统中，这是允许的，但如果你的系统涉及人事管理，单位和部门与人事系统的联系要比与权限管理系统的联系强得多，把它们放在人事系统应该更合理，更高内聚。
实际上，权限系统与单位和部门类的联系不强的，用户的权限可以由其登录时“映射”到角色来实现，之后，权限就由这个角色来决定，单位和部门只在登录时与权限系统发生联系，之后就与权限系统无关（当然不是绝对）。这是设计方面的问题，是否需要这么复杂的设计来解耦，根据需要而定。
说到权限管理，我就再罗嗦几句。
出于易用的原因，把单位和部门类这两个类放在权限管理系统中，这是允许的，但如果你的系统涉及人事管理，单位和部门与人事系统的联系要比与权限管理系统的联系强得多，把它们放在人事系统应该更合理，更高内聚。
实际上，权限系统与单位和部门类的联系不强的，用户的权限可以由其登录时“映射”到角色来实现，之后，权限就由这个角色来决定，单位和部门只在登录时与权限系统发生联系，之后就与权限系统无关（当然不是绝对）。这是设计方面的问题，是否需要这么复杂的设计来解耦，根据需要而定。
#12
我想楼主可能低估了设计的复杂程度，模块的划分是设计的一个关键部分。首先设计的目标本身就复杂，首先要尽量实现客户提出的要求，还要可以接受的运行效率，还有设法将低成本，还要为维护考虑，可理解性可扩展性可重用性等等；这些目标之间还有权重的问题。除了目标之外，还有设计的输入和约束条件，比如可以选择那些不同的算法、在哪个平台上实现，是不是要重用以前写的代码或者购买第三方的类库等等。在设计中只有上面提到的一个方面的看法不一样，最后设计结果就会差别很大。
如果想解决沟通效率的问题，也不是很难，通常的做法是让一个人来划分模块，确定模块的接口，其他人则检查这个设计是不是有严重问题。如果设计是集体完成的，效率就比较低。
如果是考虑那些类属于那些模块，这个是组织的问题，组织的好的确比较容易查找需要的类。我一般用聚合关系作为线索组织复杂的设计，比如设计了一个权限管理器对象，为用户提供权限管理功能，这个权限管理器聚合了用户类、角色类、权限类的实例，则权限管理器对象可以作为一个模块，而用户类、角色类、权限类属于这个模块。
同一个领域的概念对应的对象，不应该聚合到不同的对象中，比如如果还有一个用户管理器的话，不能让用户管理器和权限管理器同时聚合用户类对象，只能一个聚合一个关联。
只有在不同领域（不同的抽象层次的概念）的概念，比如权限管理器和链表，这两个概念属于不同领域，链表概念更抽象，重用范围更大，可以作为底层的类，聚合到不同的具体领域概念中，而且做好经过派生之后再聚合。
另外不同抽象层次的概念对应的类，不能使用双向的关系，比如双相关联，双向依赖等等，只能让具体的概念看见抽象的概念，抽象概念类不能看见具体概念类。另外单向关系，只能使用继承关系和单向依赖关系，而一般不应该使用关联关系和聚合关系。
一般我使用这些原则来组织类之间关系，效果还比较好。
如果想解决沟通效率的问题，也不是很难，通常的做法是让一个人来划分模块，确定模块的接口，其他人则检查这个设计是不是有严重问题。如果设计是集体完成的，效率就比较低。
如果是考虑那些类属于那些模块，这个是组织的问题，组织的好的确比较容易查找需要的类。我一般用聚合关系作为线索组织复杂的设计，比如设计了一个权限管理器对象，为用户提供权限管理功能，这个权限管理器聚合了用户类、角色类、权限类的实例，则权限管理器对象可以作为一个模块，而用户类、角色类、权限类属于这个模块。
同一个领域的概念对应的对象，不应该聚合到不同的对象中，比如如果还有一个用户管理器的话，不能让用户管理器和权限管理器同时聚合用户类对象，只能一个聚合一个关联。
只有在不同领域（不同的抽象层次的概念）的概念，比如权限管理器和链表，这两个概念属于不同领域，链表概念更抽象，重用范围更大，可以作为底层的类，聚合到不同的具体领域概念中，而且做好经过派生之后再聚合。
另外不同抽象层次的概念对应的类，不能使用双向的关系，比如双相关联，双向依赖等等，只能让具体的概念看见抽象的概念，抽象概念类不能看见具体概念类。另外单向关系，只能使用继承关系和单向依赖关系，而一般不应该使用关联关系和聚合关系。
一般我使用这些原则来组织类之间关系，效果还比较好。
#13
我以前面对的业务比较多的单位，主要的部门有四个，其它有七个，部门下分小队，总共二十一个。要把所部门，小队的管理过程中涉及的对象，以及这些对象的日常处理，到月末，年末的统计分析报表，都一一处理好，要把所有数据整合好，还要应客户对处理流程，甚至小队，部门的变动，如果去到类的粒度并不现实。现在改得最多的是涉及流程、数据对象的类，报表，相反大的系统框架改动很少。
设计一些抽象类以减少改动，这方面的工作也做了不少。
现在要进行一个新的项目，系统框架和模块的设计应是重要的一步。以前这方面的设计是全部设计人员都参与的，花了几个月的时间，总体没有问题，但细节设计得不好，原因很多这里不提。现在分开设计，每人负责一部分，但要定个大家可遵守的规则，以便讨论审核。大家有何想法？
设计一些抽象类以减少改动，这方面的工作也做了不少。
现在要进行一个新的项目，系统框架和模块的设计应是重要的一步。以前这方面的设计是全部设计人员都参与的，花了几个月的时间，总体没有问题，但细节设计得不好，原因很多这里不提。现在分开设计，每人负责一部分，但要定个大家可遵守的规则，以便讨论审核。大家有何想法？
#14
细节部分分开设计有时候也不可避免，每个人都设计完之后一起讨论接口，就可以避免模块交互的错误。
制定成文的规则很难，不过没有规则也不一定就不能统一风格，比如有设计模式可参考的就参考设计模式，每次讨论接口设计的时候可以研究那个接口设计的比较好（而不是讨论是否可行，可行的方案很多），这样久了每个人之间就会有默契，其实就是不成文的规则。
制定成文的规则很难，不过没有规则也不一定就不能统一风格，比如有设计模式可参考的就参考设计模式，每次讨论接口设计的时候可以研究那个接口设计的比较好（而不是讨论是否可行，可行的方案很多），这样久了每个人之间就会有默契，其实就是不成文的规则。