您的位置:首页 > 运维架构 > 网站架构

领域驱动设计-学习笔记 分层架构

2010-11-20 09:57 375 查看
在面向对象的程序中,用户界面(UI)、数据库和其他支持代码,经常被直接写到业务对象中去。在UI和数据库脚本的行为中嵌入额外的业务逻辑。出现这种情况是因为层短期的观点看,它是使系统运行起来的最容易的方式。

当与领域相关的代码和大量的其他代码混在一起时,就很难阅读并理解了。对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI 代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变都不切实际,而且自动化测试也难已使用.如果在程序的每一个行为中包括了所有的技术和逻辑,那么它必须很简单,否则会难以理解。



用户界面层
负责向用户显示信息,并且解析用户命令。外部的执行者有时可能会是其他的计算机系统,不一定非是人
应用层
定义软件可以完成的工作,并且指挥具有丰富含义的领域对象来解决问题。这个层附负责的任务对业务影响深远,对跟其他系统的应用层进行交互非常必要。这个层要保存简练。它不包括处理业务规则或知识。只是给下一层中相互协作的领域对象协调任务、委托工作。在这个层次中不反映业务情况的状态,但反映用户或程序的任务进度的状态
领域层
负责表示业务概念、业务状况的信息以及业务规则。尽管保存这些内容的技术细节由基础结构层兰完成。反映业务在的状态在该层中被控制和使用。这一层是业务软件的核心
基础结构层
为上册提供通用的技术能力;应用的消息发送、领域持久化,为用户加盟绘制窗口等。提供架构框架,基本结构层还可以支持这四层之间的交互模式
在一个复杂的程序进行层次划分。为每一层进行设计,每层都是内聚的而且只依赖于它的下层。采的用标准的架构模式来完成与上层松散关联。将所有与领域模型相关的代码集中在一层,并且家它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上,不需要关心他们自己的显示、存储和管理应用任务等内容。这样使模型发展得足够丰富和清晰,足以抓住本质的业务知识并实现它。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: