ps:这本书理论性很强,刚开始翻了几章就看不下去了,现在再拿出来翻,确实感觉有种领悟,逐以记录
在交流中的领域模型中,讨论了模型在交流中的产生、实现、意义的一些讨论,那么在怎么才能在编码过程中让软件与模型始终保持一致。
分离领域
领域通常只占整个软件系统的很少部分,这与它的重要性不成比例,为了集中精力,我们需要考虑将模型中的元素视为一个系统。
在有些程序中,用户界面、数据库和其他支持代码,经常被直接写到业务对象中去。短期的来看,它确实是使系统运行起来的最容易方式。但是当领域相关的代码和大量的其他代码混在一起时,就很难阅读理解了。比如,你要通过JS实现一个美丽的菜单或优化一段数据库脚本,但是它们都与领域无关。
分层
创建能够处理非常复杂任务的程序要求分离关注点,这样允许隔离地关注设计的不同部分。对软件系统的分割有各种各样的方法,软件行业确定了分层架构,尤其是确定了一些工人的标准层。分层是为了分离领域,当领域逻辑和程序的其他关注点混在一起的时,要达到一致很不现实、隔离领域实现是领域驱动设计的前提条件。
分层的基本原则是:某一层中的所有元素只能依赖与同一层的其他元素,或者依赖其直接的下层元素。向上的信息传递必须经过一些间接机制,比如回调或者Observer模式。
用户界面层 | 显示信息,解析命令 |
应用层 | 定义软件可以完成的操作,并且只会具有丰富含义的领域对象来解决问题,这个层要保持简洁,它不包括处理业务规则或者知识。 |
领域(模型)层 | 负责表示业务概念,业务状况的信息以及业务规则 |
基础结构层 | 为上层提供通用的技术能力:应用的消息发送,领域持久化等等 |
对比与我们熟悉的SSH,用户界面层应该是显示的界面、HTML、CSS、JS等;应用层应该是Struts2中的Action处理的;至于领域曾,本来应该是entity,但是由于各种原因,我们的entity只有属性,没有方法,成了贫血领域,所以还应该包括service层。至于DAO以及sprign提供的依赖注入等都应该术语基础结构层。
最后以书上专业的话做一下总结:采用标准的架构模式来完成与上层的松散关联。将所有与领域相关的代码都集中在一层,并且将它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上,不需要关系它们自己的显示、存储和管理应用任务等额呢绒。这样使模型发展得足够丰富和清晰,注意抓住本质的业务只是并实现它。
层间的关联
在分层以后,层之间必须连接起来,把各个层连接起来而不影响分层给设计带来的好处,是许多模式所追求的。
最早用来连接用户界面层、应用层和领域曾的模式是模型-视图-控制器(Model-View-Controller,MVC)。
模型属于领域层,领域层是模型和所有与其直接相关的设计元素的显现。
选择
对于一个没有经验的开发团队,很可能走向两种极端,要么花费大量时间来掌握领域设计,最后却发现只是开发了一个简单的系统,没有丰富的功能。或者根本不采用该技术,而使用一些“旁门左道”,比如智能UI。
一个老练的开发人员,可以在要求很高的项目时,从领域驱动设计中获得很多好处而要求不高的项目,它也能使用一些快捷的方法。
有许多的开发风格,关键在于你的决断,必须在复杂性和灵活性之间做出考虑。