软件生产与模型（一）：分离领域

ps：这本书理论性很强，刚开始翻了几章就看不下去了，现在再拿出来翻，确实感觉有种领悟，逐以记录

 

 

在交流中的领域模型中，讨论了模型在交流中的产生、实现、意义的一些讨论，那么在怎么才能在编码过程中让软件与模型始终保持一致。

 

分离领域 

领域通常只占整个软件系统的很少部分，这与它的重要性不成比例，为了集中精力，我们需要考虑将模型中的元素视为一个系统。 

在有些程序中，用户界面、数据库和其他支持代码，经常被直接写到业务对象中去。短期的来看，它确实是使系统运行起来的最容易方式。但是当领域相关的代码和大量的其他代码混在一起时，就很难阅读理解了。比如，你要通过JS实现一个美丽的菜单或优化一段数据库脚本，但是它们都与领域无关。

 

分层

创建能够处理非常复杂任务的程序要求分离关注点，这样允许隔离地关注设计的不同部分。对软件系统的分割有各种各样的方法，软件行业确定了分层架构，尤其是确定了一些工人的标准层。分层是为了分离领域，当领域逻辑和程序的其他关注点混在一起的时，要达到一致很不现实、隔离领域实现是领域驱动设计的前提条件。

 

分层的基本原则是：某一层中的所有元素只能依赖与同一层的其他元素，或者依赖其直接的下层元素。向上的信息传递必须经过一些间接机制，比如回调或者Observer模式。

 

用户界面层	显示信息，解析命令
应用层	定义软件可以完成的操作，并且只会具有丰富含义的领域对象来解决问题，这个层要保持简洁，它不包括处理业务规则或者知识。
领域（模型）层	负责表示业务概念，业务状况的信息以及业务规则
基础结构层	为上层提供通用的技术能力：应用的消息发送，领域持久化等等

 

对比与我们熟悉的SSH，用户界面层应该是显示的界面、HTML、CSS、JS等；应用层应该是Struts2中的Action处理的；至于领域曾，本来应该是entity，但是由于各种原因，我们的entity只有属性，没有方法，成了贫血领域，所以还应该包括service层。至于DAO以及sprign提供的依赖注入等都应该术语基础结构层。

最后以书上专业的话做一下总结：采用标准的架构模式来完成与上层的松散关联。将所有与领域相关的代码都集中在一层，并且将它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上，不需要关系它们自己的显示、存储和管理应用任务等额呢绒。这样使模型发展得足够丰富和清晰，注意抓住本质的业务只是并实现它。

 

层间的关联

在分层以后，层之间必须连接起来，把各个层连接起来而不影响分层给设计带来的好处，是许多模式所追求的。

最早用来连接用户界面层、应用层和领域曾的模式是模型-视图-控制器（Model-View-Controller，MVC）。

模型属于领域层，领域层是模型和所有与其直接相关的设计元素的显现。

 

选择

对于一个没有经验的开发团队，很可能走向两种极端，要么花费大量时间来掌握领域设计，最后却发现只是开发了一个简单的系统，没有丰富的功能。或者根本不采用该技术，而使用一些“旁门左道”，比如智能UI。

一个老练的开发人员，可以在要求很高的项目时，从领域驱动设计中获得很多好处而要求不高的项目，它也能使用一些快捷的方法。

有许多的开发风格，关键在于你的决断，必须在复杂性和灵活性之间做出考虑。