标签:post api rest 依赖倒置 用户 读书 factory extern 处理
本文算是《领域驱动设计》这本书的读书笔记,加上自己的一些读后感。网上有很多这本书的读书笔记,但是都是别人的,不如自己总结的理解深刻。建议大家在读这本书时结合《实现领域驱动设计》一起看,同时,一定要去实际建模和编码,理论联系实际才能得其精髓。
本文是【DDD & 重构】系列文章的第一篇,可参考:通过业务系统的重构实践DDD
DDD是Domain driven design(领域驱动设计)的简称,是一种软件设计和开发的方法论,特别适用于复杂业务领域软件设计和开发。可参考wiki: Domain-driven_design
划分领域边界,边界内领域模型保持一致,强调内聚,并与边界外的领域模型解耦。
有唯一标识,可变的业务实体对象,它有着自己的生命周期。比如User、帖子等。
没有唯一业务标识,通常依附于其他领域实体,值对象的内容不可变,要么被整体替换。如:用户点赞行为等。
是一组业务关联度很强的实体/值对象集合,每个聚合都有一个根实体(Root Entity),通过根实体可以路由到整个聚合。
领域中发生的异步处理事件、异步消息通知等,比如:异步写入的登录历史记录。通常借助消息队列实现。
当某些业务行为无法归类到某一个Entity/Value Object时,我们便可以创建领域服务来完成。比如:账户转账场景,涉及到两个不同的Account实体,再比如社区的敏感词过滤场景,帖子可以用,评论亦可以用,因此可以抽离到ContentFilter中完成。
严格意义上将仓库是基础设施层的东西,但是为了保持领域模型的整体性,我们将仓库的接口定义放到领域中,这样可以在领域中约束实体/值对象的增删改查接口,同时还可以方便地完成仓库的内存形式实现,使得领域模型弱依赖于持久化层。这一点在书中被成为‘依赖倒置’(参考《实现领域驱动设计》P372)。
用于复杂领域对象的创建/重建。重建是指通过respostory加载持久化对象后,重建领域对象。
User Interface —— 用户界面层。提供与用户/调用者交互的接口,可以是View,也可以是Restful api,还可以是二进制形式的tcp协议接口等。
Application —— 应用服务层。组合domain和infrastructure,完成具体的业务逻辑。
Domain —— 业务领域层。是ddd中的核心层,内聚所有的业务逻辑,保持领域的一致性。通常他可能会用到infrastructure层的公共组件。
Infrastructure —— 基础设施层。提供公共服务组件,比如validation、登录态校验、trace日志记录等等。
这张图囊括了DDD中的所有核心概念,上面部分是战术相关,下面部分是战略相关。不再赘述,建议读者执行查阅DDD原书,有详细介绍。值得反复细读。
在评论区,附上自己的思考,会不间断更新。欢迎大家写上你们的理解。
标签:post api rest 依赖倒置 用户 读书 factory extern 处理
原文地址:http://www.cnblogs.com/daoqidelv/p/7492447.html