架构设计-逻辑层

标签: IT项目管理 | 发表时间:2014-11-23 01:13 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
知乎看到一个问题,也是当前在软件设计开发中普遍存在的一个问题,如下:

现在要开发一个业务逻辑比较复杂的项目,但是在网上看了设计模式的思想后感觉自己以前写的东西扩展性都不好,接口定义也不合适,都是一个实体类一个接口,项目施工也感觉不合理,感觉项目施工中应该先集中定义好接口,并完成业务逻辑,然后在具体实现接口,不知道这样想是不是正确?

对于这个问题,其实在我前面关于领域驱动设计的文章和读书笔记里面已经专门谈到过,再简单回答下。

首先我们看下模式是什么? 模式是特定场景下解决特定问题的方法或最佳实践,因此最重要的是了解清楚有扩展性需求,有需要灵活应对的变更需求的特定场景。场景想清楚了你才可能想应该用什么样的设计模式去解决问题。如果没有这些场景,为何一定要套用设计模式呢?简单的对设计模式的套用往往都是过度设计,并不值得推荐。

根据你的问题描述,初步分析整个系统还是以数据库DB为主导的一个系统设计和实现方法,而不是以对象为主导的设计方法和思路。在原来的项目中我们也看到相当多的这种设计实现方法,虽然用了O/R Mapping,但是实体对象全部是数据库表,接口方法全部是CRUD,这种方法在应对的简单的无相关性表单对象维护可能还可以,但是一旦面对比较复杂的业务系统或业务场景,很难谈得上真正的可扩展性。

对于一个业务逻辑比较复杂的项目,那么就要先考虑我们的业务逻辑层在哪里?业务逻辑层里面是否真正有业务逻辑的抽象和设计?还是业务逻辑都被放到数据库,数据层或前端去了?很多项目有业务逻辑层的类,但是基本都是空的,没有对业务逻辑进行抽象。这也是领域驱动设计里面谈到的贫血的领域层,一个是没有领域业务对象的概念(领域模型中的聚合根),一个是没有明确的粗粒度的业务规则逻辑处理层。

如何让业务逻辑层真正起到作用,这里面首先第一重要的还是要从DB数据库对象抽象出真正的领域对象,如订单,合同,项目,这些是领域对象。一个领域对象下面对应了多张数据库表。一个领域对象本身应该是高内聚的,不应该开放和暴露的坚决不暴露,仅仅暴露领域对象应该暴露的接口方法和能力。这个时候的实体类是在简单数据库表实体类的上一层。实体类可以有方法,也可以是实体和方法分离,实体类仅仅是DTO对象都没有问题。

在上面这步完成后,接着要解决的是还有些复杂的业务规则是跨了多个实体对象的,也是前面说到的粗粒度的业务规则逻辑处理层。这些规则处理放到任何一个实体类里面去都不合适,在领域驱动设计里面将其放到service层去处理。但是更加重要的是想说,需要针对这种场景有单独的业务规则或逻辑处理类,这些类似RUP方法里面的控制类,本身并不会有对应的数据库表操作,而是对已有的各个实体类方法的调用和组合,在过程中增加了业务规则的处理。

这些业务规则类或方法如何寻找?最简单的往往是从需求里面的业务规则入手,首先要需求里面的业务规则同需求基本流,扩展流分离出来,再来看这些业务对象的处理和实现是否需要跨多个领域对象实体。其次需要对关键用例实现进行分析,在关键用例的实现流中,类似序列图这种分析中,是否出现了跨多个领域对象多次操作后才需要返回前端的业务场景。那么就说明这些多次操作和规则可以在逻辑层完成,而不是暴露到前端或action层去组装。

最后简单总结下上面的内容

1.我所谈的复杂业务规则究竟在哪里?我能否清楚描述和定义并从基本流或扩展流剥离?
2.我需要的可扩展性究竟是应对何种场景扩展和变更?是否真正需要可扩展性设计?
3.从领域对象和专门业务逻辑处理类两个层面来解决贫血的逻辑层的问题。
4.转变传统的围绕数据库对象为中心的逆向设计方法,为围绕领域对象的业务处理和交互分析的方法。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [架构 设计 逻辑] 推荐:

架构设计-逻辑层

- - 人月神话的BLOG
知乎看到一个问题,也是当前在软件设计开发中普遍存在的一个问题,如下:. 现在要开发一个业务逻辑比较复杂的项目,但是在网上看了设计模式的思想后感觉自己以前写的东西扩展性都不好,接口定义也不合适,都是一个实体类一个接口,项目施工也感觉不合理,感觉项目施工中应该先集中定义好接口,并完成业务逻辑,然后在具体实现接口,不知道这样想是不是正确.

设计中的五个逻辑

- - 雷锋网
【编者按】本文由 网易UEDC所写 . 逻辑的存在如同我们日常生活一样. 种族之间的相互不一影响着人类的认知,美国人的独立平等可不一定能让各就其位等级严格的日本人接受. 所以,作者理解的设计中的逻辑,是常规意识下有规范有顺序,有理有据,小到一个符号也能说明和画面的关系以及他存在的意义的. 逻辑( 理则学),源自古典 希腊语λόγος (logos),最初的意思是“ 词语”或“ 言语”,还引申出意思“思维”或“推理”.

浅谈设计中的逻辑

- - 互联网的那点事
逻辑( 理则学),源自古典 希腊语λόγος (logos),最初的意思是“ 词语”或“ 言语”,还引申出意思“思维”或“推理”. 逻辑经常被认为对 论证评价准则的 研究,尽管逻辑的精确定义在 哲学家之间尚有争议的事情. 这个主题还是有所依据的, 逻辑学家的任务是相同的:提出大量的有效和谬误的 推论,从而允许人们区别出好论证和坏论证.

板鞋逻辑:Sneakerology专卖店设计赏

- Vendi - 理想生活实验室
姑娘爱高跟,小伙儿就爱 Sneakers,而买鞋最佳的场景就是有海量的款式给你挑选,随意看随意试. 由 Facet Studio 所设计的板鞋专卖店 Sneakerology 能够满足你的无穷欲望,这所店内墙面由 281 个 20×60cm 见方的格子组成,清爽地放上各色鞋子展示,而店铺中心设有触屏设备,可以通过它来查询每一双鞋子的传奇故事.

软件架构设计

- - 企业架构 - ITeye博客
软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:. 1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.

架构设计和概要设计

- - 人月神话的BLOG
初步再来探讨下架构设计和概要设计的区别和边界问题. 架构设计包括了功能性架构和技术架构设计两个部分的内容,功能性架构解决业务流程和功能问题,而技术架构解决非功能性需求等问题. 两种架构都包括了动态和静态两个方面的内容,对于功能性架构中动态部分为业务流程驱动全局用例,用例驱动的用例实现等;对于技术架构中动态部分为架构运行机制,而静态部分为框架,分层等方面的内容.

产品设计中的逻辑规则——增删查改显算传

- - 牛国柱
产品如同人一样,有样貌、皮肤等外在结构,也有筋骨、神经网络等内在的体系. 在产品设计及规划中,产品经理除了要对UI、UE等外在负责外,还需要对产品的筋骨、神经网络负责. 产品的筋骨、神经网络即产品隐含的逻辑规则,是产品运转正常的保证. 设计合理且逻辑清晰的规则,是产品成功的必要条件. 而网络广告产品,可能是网络产品中逻辑规则最复杂的一类产品.

浅谈淘宝类目属性体系:商品搜索背后的逻辑架构

- - 人人都是产品经理
[核心提示] 淘宝拥有百万家商户和超过10亿的商品数,它如何让用户精准地找到想要的商品呢. 淘宝目前在线商品数超过 10 亿,如何精准的帮助用户找到他想要的商品呢. 经过多年的探索,淘宝通过建立一套完整的类目属性体系,终于较好的解决了这一问题,今天就跟大家一起来谈谈淘宝的类目属性体系. 2003 年淘宝刚上线时,商品量很少,没有分类.

分层架构设计原则

- - 博客园_首页
通常一个软件系统都包含不同部分互相交互耦合,我们希望设计能够将系统划分为有意义的各个部件,各个部件能够独立的开发、演进、部署. 这时整体性的设计已经无法满足这些挑战,这就需要我们对系统进行合理清晰的划分. 通常我们为待开发的系统定义多个层次,每一层完成独立的功能. 1:系统分为多层,每层完成独立的功能,层内部继续细分子模块,每层能够独立演进、部署.

社区讨论:Android的架构设计

- - InfoQ cn
最近,开发者在知乎社区中就Android的架构设计展开了 讨论. 有人问“Android 架构设计的思想与原则是什么. 最近工作中遇到了Android中的权限问题,发现Android确实是开源的,但并不开放,比如权限控管就相当严格,限制做很多事情,这一点得益于Linux内核. 这也勾起来对其架构研究的兴趣,不知到哪位能够深度剖析下Android架构设计的思想与原则.