软件服务模块的划分原则

复杂的系统，最好先按业务领域横向拆分成可独立部署的子系统，每个子系统内部再按技术（主要是业务层和Web层）纵向拆分成不同的模块。


子系统之间，前台通过SSO集成，后台通过SOA（Dubbo之类）集成。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
原则就是不要从技术角度拆分应用。
目前业内都是按模块划分的。
举个简单电商的例子。
可能是这样分模块：电商portal、订单、会员、商品、优惠、支付。
每个模块都只负责自己的一块业务，同时对其他模块开放必要的接口。
这种情况下，哪个模块有变动，只要接口不变完全不影响其他应用。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
请问模块和服务在认知理解上的区分准则：
1、服务是为实现模块功能提供支持的。
2、服务与业务无关。模块也业务紧密关联，业务也就是你这个系统的目的和价值。
3、用户不需要明白服务，也不理解服务，服务是针对开发人员的。
4、服务不与某个特定模块相关。
5、模块都有对应的界面，服务一般没有界面，或者是通用界面。
6、模块相对各自独立，服务一般是支持所有模块的，服务不会和某个特定模块绑定。
7、模块依赖服务，但是服务绝对不可以依赖模块。（这个很关键）


报表展示、登录、邮件、短信、报表制作划分成了服务。
 那么为什么，比如“发布新闻”不能成为服务呢
1、因为“发布新闻”是典型的业务，你做这个系统就是为了实现这些业务给用户用的，所有“发布新闻”是业务模块。
2、在命名上，你可以把所有业务模块放在bussiness下，把服务放在framework下。




>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1、实体的专用性
1)        尽量的保持实体的专用性，也就是一个功能的方法，虽然和两外一个方法的返回结果类似，可能只需要添加一两个属性，这样的情况，重新建立实体，方便后面可能对这两个方法返回内容的修改不至于相互影响。
2)        尽量保持一个实体中的每一个属性，每一个被赋值的属性，将来都会用到，否则减少实体的属性，或者新建一个实体，使用正好合适的属性个数。
 


3)        分离添加和显示用的实体，因为添加可能不是每个字段都需要赋值，或者一些值是默认值。
 


4)        分离不同类型的用户使用的实体，尽管是相同的功能。可以在类名添加ForPlanter之类的后缀来解决。因为不同用户关注的点不同，关注的属性肯定不相同。而且修改也不影响其他类型用户的使用。
 


2、方法的专用性
 


保持方法的专用性，分离不同用户的业务方法和数据访问方法。也是为了后面的修改，不至于影响其他用户功能的使用。


 


3、系统划分
先按照功能模块或者是服务的对象主体来划分系统，划分为子系统。然后再每个子系统中分层，子系统之间的交互使用接口。子系统相关的后台代码独立，方便日后维护升级。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
有时候很多事情是相反的，例如：安全性和运行效率，扩展性和运行效率。
你要安全，就需要验证每个参数，各种情况，效率就低了点点。当然了，这个可能不明显。


你要可扩展性，就要分层，要分层部署，要部署在多台服务器，就会比部署在一台机器慢，因为有了网络延迟，有了网络通信和数据传递，还要数据解析，影响运行效率，但是带来了更大的好处，可扩展性和容错性。


这就需要衡量，在两者之间找到合适的分割。就想模块划分一样，也需要衡量，不是简单的划分。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
一般应该按功能点分，按层分的话，一定是有详细的设计文档
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
按任务需求进行模块划分的主要步骤如下：
(1)     分析系统的需求，得出需求列表；
(2)     对需求进行归类，并划分出优先级；
(3)     根据需求对系统进行模块分析，抽取出核心模块；
(4)     将核心模块进行细化扩展，逐层得到各个子模块，完成模块划分。
在很多情况下，在划分任务需求的时候，有些需求和很多个模块均有联系，这个时候，通过需求来确定模块的划分就不能够降低模块之间的耦合了。而且有些模块划分出来里面涉及的数据类型多种多样，显然这个时候根据系统所抽象出来的数据模型来进行模块划分更加有利。
在系统进行模块划分之前，往往都会有一个数据模型的抽象过程，根据系统的特性抽象出能够代表系统的数据模型。根据数据模型来进行模块划分，可以充分降低系统之间的数据耦合度。按照数据模型进行模块的划分，降低每个模块所包含的数据复杂程度，简化数据接口设计。同时，对于数据的封装可以起到良好的作用，提高了系统的封闭性。
抽象数据模型的模块划分方案是一种基于面向对象的思想进行的。这种思想的特点就是不以系统的需求作为模块的划分方法，而是以抽象出系统的数据对象模型的思想对模块进行划分。而利用这种思想进行模块划分的主要好处能够接近人的思维方式对问题进行划分，提高系统的可理解性，可以从较高层次上对系统进行把握！
按照数据模型进行模块划分的主要步骤如下：
(1)     根据系统框架抽象出系统的核心数据模型；
(2)     根据核心数据模型将系统功能细化，并将数据模型与视图等剥离，细化数据的流向；
(3)     依据数据的流向制定模块和接口，完成模块划分。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
在很多项目设计过程中对于模块划分大多都是基于功能进行划分。这样划分有一个好处，由于在一个项目的设计过程中，有着诸多的需求。而很多需求都可以进行归类，根据功能需求分类的方法进行模块的划分。可以让需求在归类上得到明确的划分，而且通过功能需求进行软件的模块划分使得功能分解，任务分配等方面都有较好的分解。
按照任务需求进行模块划分是一种基于面向过程的划分方法，利用面向过程的思想进行系统设计的好处是能够清晰的了解系统的开发流程。对于任务的分工、管理，系统功能接口的制定在面向过程的思想中都能够得到良好的体现。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


软件设计过程中通过对软件进行模块划分可以达到一下的好处：
(1)     使程序实现的逻辑更加清晰，可读性强。
(2)     使多人合作开发的分工更加明确，容易控制。
(3)     能充分利用可以重用的代码。
(4)     抽象出可公用的模块，可维护性强，以避免同一处修改在多个地方出现。
(5)     系统运行可方便地选择不同的流程。
(6)     可基于模块化设计优秀的遗留系统，方便的组装开发新的相似系统，甚至一个全新的系统。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
“高内聚、低耦合” ---- 软件模块划分的目的
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
软件模块划分应基于什么原则进行呢？ 
  基于功能划分、基于层次划分、基于专业划分、基于需求划分？


当前常见的划分方式为基于专业领域的划分，如：用户操作GUI，数据处理、网络接口等专业领域划分。按专业领域划分确实可以解决很多实现上的问题，这里指的是功能上的实现。


实现了在同一模块中不允许存在两个不同专业领域的内容的要求
更有利于模块的实现


有了该划分是否就足够了呢？多年的项目经验告诉我这的确还不够。


模块划分清楚后各个模块能够实现它的功能，但我们要的是一个完整的产品，是一个多模块的有机结合，但只是将多模块堆积在一起往往!=产品。为什么会这样呢？
因此软件模块的划分
    实现上需要基于专业领域的划分
    管理上需要基于客户需求的划分
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
【问】为什么模块要先按功能划分，再按层划分？
【答】相对于产品功能本身的变化，统一对某一个层面进行集中调整（比如网络层、界面层）的可能性不大，这一类调整通常是对原有技术方案的调整，影响很大，需要完整的程序和测试计划，这种情况出现时，必然会违背基本原则3，而与先功能划分，还是先按层划分没有关系。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 


1. 设计一般来说是个学习迭代的过程、通过不断的评审&确认&改善达到成熟. 但是前提必须写出设计文档，而不能仅仅停留在脑袋里。
2. 分层、抽象、归纳、汇总 是设计的主要方法。其中分层是最最基本的，而是绝大数设计人员不能掌握的（这个有点悲剧），归纳是常见的方法。
3.交互的设计往往是人们关注的重点，所以也要特别注意、特别设计。对于画面的风格、操作等我的理解是“美的事物，任何人都觉得美”。
4. 设计的完整性、严密性、可用性是成功的主要因素。
5.设计不等同于创造和创新，但是好的设计一定包含各种创新。
6. 多看看其他的系统，功能、交互方法、实现方式等，才会有思路，有想法。比如，画面色彩、布局等可以参考日本的网站，交互参考欧美站。多看才有比较！
7.系统/产品研发就是群体学习活动，什么时候学会什么完成。需求、概要设计、详细设计中如何描述、粒度如何划分，是要在前期就要思考的，这些是研发人员的“教材”。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
高内聚低偶合
模块大小规模适当
模块的依赖关系适当等


这些在《软件工程》里够有。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
正交性是有助于使复杂设计也能紧凑的最重要特性之一。在纯正交设计的软件中，任何操作均无 副作用。每一个动作（方法调用）只做一件事，不会影响其它。


Douglas McIlroy 的“只做好一件事”的忠告是针对简单性的建议，但其实也暗含了对正交性的强调。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
可以，SOA就是这样的概念。
缺点是：
需要一个额外的单点登录模块，对安全性有要求可能得搞一套oauth服务；
用户权限控制的粒度比较粗。


优点：
也许只有比较稳定吧。


另：
还真不一定便于维护，因为功能和模块都增加了，而且还引入了在原有设计中不需要的技术(比如oauth和MQ)。
更容易划分责任(踢皮球)倒是真的。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
例如你去建造（开发）一幢大楼（系统），墙可以认为是组件，由它去构建大楼（系统）；模块就像挂在墙上的钟、空调、画框等等；而插件只是为特定的物品（程序）定制，不能应用于别的类似的物品（程序），就好比钉在墙和画框里的钉子，并不适合去钉空调。
































将程序划分成模块的原则和方法是什么？
------解决思路----------------------
高内聚
低耦合
------解决思路----------------------
模块是从需求分析中来的，需求工程中有一些关于需求分类的方法，可以参考。
------解决思路----------------------
你要做的系统本身就是划分成一个一个的子系统的，你只要找准就可以了


答案就在问题本身。
------解决思路----------------------
只根据需要
------解决思路----------------------
多实践，结合面向对象技术来看。


不是把程序分模块，而是把系统划分模块。
系统就是问题域，系统划分过程就是对问题分解过程。
所以明确需求而且对问题域研究透才能划分得好。这是大方面。


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


















-------------------------------------------循环依赖--------------------------------------------------------
    1.一个就是依赖其它模块的业务方法
　　当是依赖其它模块的业务方法的时候，我们可以考虑将这个业务方法中的业务逻辑移到自己模块中的业务方法中。
　　2.另一个是依赖其它模块的实体类
　　当是依赖其它模块的实体类时，我们也可以考虑将这个实体类移动到自己模块中。
　　除此之外还有另一个方法，就是查询的实体结果使用数组的方式。这样就不会依赖其它模块的实体了，但这样又会造成代码可读性差难以维护的问题。
　　如果系统中的模块太多时，可以考虑将模块之间双向依赖的业务方法和实体类统一放到一个公共模块中，这样所有的双向依赖问题就解决了。
-------------------------------------------为什么要模块划分-----------------------------------------------------------------
功能模块化的根据是，如果一个问题有多个问题组合而成，那么这个组合问题的复杂程度将大于分别考虑这个问题时的复杂程度之和。这个结论使得人们乐于利用功能模块化方法将复杂的问题分解成许多容易解决的局部问题
1，功能模块独立的概念是功能模块化、抽象、信息隐蔽和局部化概念的直接结果。 
2，功能模块独立性是由内聚性和耦合性两个定性指标来度量的。内聚性是度量一个功能模块内功能强度的一个相对指标。耦合性则用来度量功能模块之间的相互联系的程度。
--------------------------------------------------------------------------------------------------------------------------------




































----------------------------------------------------------
单纯看代码没意义，对项目代码的理解一般遵循这几步：一、对采用开发框架的文件结构、逻辑组织结构的理解；二、对业务逻辑的理解，就是去了解这块儿代码是做什么的，正向的去看，如果让你写，你会怎样写，然后对比别人的实现方式；三、代码细节看正常实现过程中有哪些细节，哪些坑，并怎么解决的。
-------------------------------------------------------------
根据前面对系统的需求分析，可以得到系统的模块划分如下
--------------------------------------------------------------
当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉 及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容，或者 说软件需求已经会兼顾部分软件架构设计的内容，因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要 去了解涉及到UCD，交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入
-------------------------------------------------------------------
拆分还是有很多难度的 比如事务 跨库关联 从长远角度看 你们技术说得没错 需要提早预计一些容量
--------------------------------------------------------------------------------
















>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


面向对象编程(Object-Oreinted Programming) 是一种编程范式。指在设计程序时大量运用类实例对象的方式。OOP一旦在项目中被运用，就成了时刻要考虑的东西。
面向服务架构(Service-Oreinted Architecture) 是将软件设计成一组可互操作的服务的一套原则或方法论。通常在考虑系统架构时才会触及SOA。
基于组件开发(Component-Based Development) 是一种软件工程实践，设计时通常要求组件之间高内聚，松耦合。其接口可能是OO的，调用方式可能是以Service的方式。基于组件开发关注系统层次、子系统边界和子系统间通讯的的设计，处于代码层面但不像OOP的一样是时刻需要运用的东西。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
对于SOA的服务粒度，我们谈的比较多的是SOA本身是一种粗粒度服务设计的思路。内部的业务规则和操作可能比较复杂，但是组件之间的交互需要屏蔽这些复杂性，是粗粒度的一种服务。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>