软件架构设计感悟-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

软件架构设计感悟

简介:

如果你要开一家能处理公司相关业务的公司。你将要面对如何设计这个公司的职能部门,定义工作岗位,业务如何通过这些职能部门进行处理的问题。如果是10人以内小公司,那无所谓。如果是上百人的公司,那么就得有详细的职能部门划分,有规范的业务办理流程。
软件的架构设计与设置一家公司的组织架构有异曲同工之处。

接口类,其实就是定义一个工作岗位。定义了这个岗位的职能范围。
每个类实例化的对象,其实都是这个工作岗位上的员工。

设置一个工作岗位之前,我们一定要想清楚这个岗位的职能范围。要给这个岗位命一个明确(一看就知道它的职能)的岗位名称。
这个岗位上的员工只能从事岗位职能范围内的工作。我们不能随意给这个岗位添加与这个岗位预想职能范围不符的职责。比如:“项目经理”,不能因为开发需发把编码的工作强加给它。职能范围要划清,什么该做,什么不该做,一定要明了。(单一法则)

社会很多关系都是上下级关系的。一个工作岗位上可能手下会有几个别的岗位。如:项目经理下可能会有软件组长、硬件组长、平台组长。而这些组长下,还会有其它岗位。(组合模式)

下属辞职必须要与上级解除上下级关系(人都走了,我怎么让他工作)。上级也可以为岗位招聘新员工(new成员变量)。如果上级被解职,那么其有义务辞掉(delete)其下属(不能不干事儿领空饷)。

上级可以向下级下达工作指令(直接调用)。下级属需要上级协助,那么可以向上汇报(发信号)。如果直属上级不能处理,可以接着向上汇报,直到被上级处理。(职责链)

一个良好的架构,有很明朗的业务流程规则。当我们在增添一个新的业务流程的时候,我们希望一眼就能找到最直接最正确的工作流程。而不是:“这样可以实现,那样也可以”。否则会让我们浪费大量的时间来犹豫,且最终不一定能选择到正确的实现方法。维护的人多了,各创一套,杂乱无章。

一个应用中,顶多只能有一个单例(应用实例本身)。所有的对象都应该在编制内。

想到的就这么多,欢迎指正。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: