回到目录 Lind.DDD项目主要面向敏捷,快速开发,领域驱动等,对于它的分层也是能合并的合并,比之前大叔的框架分层更粗糙一些,或者说更大胆一些,在开发人员使用上,可能会感觉更方便了,更益使用了,这就是大叔开发Lind.DDD框架的目的,让一切变得更简单... Lind.DDD层 主要是公用方法,组件,规约等,如日志组件(Logger),消息组件(Messaging),IOC,AOP,缓存(Caching),异常,请求/响应,用户授权(Authorization),安全校验,领域模型(Domai…

回到占占推荐博客索引 最近觉得自己的框架过于复杂,在实现开发使用中有些不爽,自己的朋友们也经常和我说,框架太麻烦了,要引用的类库太多:之前架构之所以这样设计,完全出于对职责分离和代码附复用的考虑,主要参考了微软的DDD大作<N_LayerAPP>这个项目,而在这几年的项目开发用,也尝到了这种职责分享框架的甜头,但在最近的开发中,也看到了其它框架的出现,如<ABP>项目,它主张简单框架,敏捷开发,在项目引用上将核心类库和持久层进行抽象分离,复用在各位领域项目之中,这在项目整个感觉上更…

基本概念: 领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:<domain-driven design –tackling complexity in the heart of software>(中文译名:领域驱动设计—软件核心复杂性应对之道)一书.,书中提出了“领域驱动设计(简称 ddd)”的概念. 领域驱动设计一般分为两个阶段: 1.   以一种领域专家.设计人员.开发人员都能理解的“通用语言”作为相互交流的工具,在不断交流的过程…

写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课.第一次骑自行车.第一次懂事.第一次和喜…

写在前面 阅读目录: 问题根源是什么? <领域驱动设计-软件核心复杂性应对之道>分层概念 Repository(仓储)职责所在? Domain Model(领域模型)重新设计 Domain Service(领域服务)的加入 MessageManager.Domain.Tests 的加入 Application Layer(应用层)的协调? Unit Of Work(工作单元)工作范围及实现? 版本发布 后记 在上一篇<我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践>…

领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家…

领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家…

DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)? 阅读目录: 问题根源是什么? <领域驱动设计-软件核心复杂性应对之道>分层概念 Repository(仓储)职责所在? Domain Model(领域模型)重新设计 Domain Service(领域服务)的加入 MessageManager.Domain.Tests 的加入 Application Layer(应用层)的协调? Unit Of Work(工作单元)工作范围及实现? 版本发布 后记 在上一…

DDD(领域驱动设计)理论结合实践   写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课…

前面几篇blog主要介绍了DDD落地架构及业务建模战术,后续几篇blog会在此基础上,讲解具体的架构实现,通过完整代码demo的形式,更好地将DDD的落地方案呈现出来.本文是架构实现讲解的第一篇,主要介绍了DDD的User Interface层的实现,详细讲解了controller.dto的职责和实现,已经UI层使用到的公共组件:CheckLogin.Loging.Validation的职责和实现细节.文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景…

原文:领域驱动设计(DDD)的实践经验分享之ORM的思考 最近一直对DDD(Domain Driven Design)很感兴趣,于是去网上找了一些文章来看看,发现它确实是个好东西.于是我去买了两本关于领域驱动设计的书本和一本企业应用架构模式的书.看了之后也掌握了一些理论基础.但总感觉需要通过做一个实际项目来测试自己所学到的知识.因为以前我开发过一个叫做“蜘蛛侠论坛”的网站,官方演示地址:http://www.entityspider.com/(论坛目前已关闭,需要源代码的可以联系我),但在我学习…

原文:领域驱动设计(DDD)的实践经验分享之持久化透明 前一篇文章中,我谈到了领域驱动设计中,关于ORM工具该如何使用的问题.谈了很多我心里的想法,大家也对我的观点做了一些回复,或多或少让我深深感觉到面向对象设计和领域驱动设计是两个不同层次的东西.你会面向对象并不代表你就会面向领域设计.后来,我无意中发现了一个网站,http://www.jdon.com,这个网站中所包含的知识在我看来非常深入,而且基本上都包含了现在一些最新的设计思想.我看了几篇文章后渐渐感觉到领域驱动设计并不是我想象中那么简单…

笔者先前参与了一个有关汽车信息的网站开发,用于显示不同品牌的汽车的信息,包括车型,发动机型号,车身尺寸和汽车报价等信息.在建模时,我们只需要创建名为Car的实体(Entity)对象.其他的信息,比如车身尺寸,都是对Car起描述作用的,因此应该建模成值对象(Value Object). 此时创建的Car对象如下: public class Car { private String id; private CarType type; private EngineType engineType; pr…

DDD(领域驱动设计)应对具体业务场景,Domain Model(领域模型)到底如何设计? 写在前面 阅读目录: 迷雾森林 找回自我 开源地址 后记 毫无疑问,领域驱动设计的核心是领域模型,领域模型的核心是实现业务逻辑,也就是说,在应对具体的业务场景的时候,实现业务逻辑是领域驱动设计最重要的一环,在写这篇博文之前,先总结下之前关于 DDD(领域驱动设计)的三篇博文: 我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践:伪领域驱动设计,只是用 .NET 实现的一个“空壳”,仅此而已.…

领域驱动设计(DDD)的实际应用   笔者先前参与了一个有关汽车信息的网站开发,用于显示不同品牌的汽车的信息,包括车型,发动机型号,车身尺寸和汽车报价等信息.在建模时,我们只需要创建名为Car的实体(Entity)对象.其他的信息,比如车身尺寸,都是对Car起描述作用的,因此应该建模成值对象(Value Object). 此时创建的Car对象如下: public class Car { private String id; private CarType type; private Engine…

领域 领域是一个组织所做的事情以及其中所包含的一切.商业机构通常会确定一个市场,然后在这个市场中销售产品和服务.每个组织都有它自己的业务范围和做事方式. 领域就是解决一个特定范围内的业务问题. 如何分析领域 在研究与建模的过程中,开发人员是不能孤军奋战的,这个时候需要找领域专家一起建模,领域专家是精通业务的任何人,他们可能是软件产品的设计者,甚至有可能是销售. 领域专家把他的知识传给开发者,让建模更符合实际业务情况,以此也能获得更好的用户体验. 子域 分而治之,DDD是一套处理复杂领域的设计方法…

混园子也有些年头了,从各个大牛那儿学了很多东西.技术这东西和中国的料理一样,其中技巧和经验,代代相传(这不是舌尖上的中国广告).转身回头一望,几年来自己也积累了一些东西,五花八门涉猎到各种方向,今日开始选一些有价值的开博分享. 首篇分享的是一个基于Mongodb的轻量级领域驱动框架,创作的起源比较杂,首先来自Mongodb,能够直接存储对象.例如: public class Person { public Person(string name) { Name = name; } public O…

摘抄自 从去年10月份开始,学了几个月的领域驱动设计(Domain Driven Design,简称DDD).主要是学习领域驱动设计之父Eric Evans的名著:<Domain-driven design:领域驱动设计:软件核心复杂性应对之道>,以及另外一本Martin Flower的<企业应用架构模式>,学习到了不少关于如何组织业务逻辑方面的知识.另外,在这个过程中也接触到了一些开源的架构和一些很好的思想.如:命令查询职责分离(Command Query Responsibil…

本文主要了在社区服务系统(ECO)中基于SpringMVC+mybatis框架对DDD的落地实现.本文为系列文章中的其中一篇,其他内容可参考:通过业务系统的重构实践DDD. 框架实现图 该框架实现基本和DDD的指导思想契合,主要分为四层,且将关注点放在了domain层.下面将逐层介绍各个组件的职责. 框架详述 User Interface层 门面层,对外以各种协议提供服务,该层需要明确定义支持的服务协议.契约等.包含: dto 包括request和response两部分,通过它定义入参和出参的契…

阅读目录: 1.开篇介绍 2.简单了解缘由(本文的前期事宜) 3.DomainModel扩展性(运用设计模式设计模型变化点) 3.1.模型扩展性 3.2.设计模式的使用(苦心专研的设计模式.设计思想可以随意使用了) 3.3.部分类的使用(封装内部对象) 3.4.高强度的OO设计(面向特定领域的高度抽象设计形成特定领域框架) 4.DomainModel业务逻辑规则配置(将扩展点分离后使用适当的配置将规则IOC进去) 5.DDD简单总结(DDD是什么?它是“战术”) 1]开篇介绍 这篇文章不会太长,…

阅读目录: 1.开篇介绍 2.简单了解缘由(本文的前期事宜) 3.DomainModel扩展性(运用设计模式设计模型变化点) 3.1.模型扩展性 3.2.设计模式的使用(苦心专研的设计模式.设计思想可以随意使用了) 3.3.部分类的使用(封装内部对象) 3.4.高强度的OO设计(面向特定领域的高度抽象设计形成特定领域框架) 4.DomainModel业务逻辑规则配置(将扩展点分离后使用适当的配置将规则IOC进去) 5.DDD简单总结(DDD是什么?它是“战术”) 1]开篇介绍 这篇文章不会太长,…

概述 DDD为复杂软件的设计提供了指导思想,其将易发生变化的业务核心域放置在限定上下文中,在确保核心域一致性和内聚性的基础上,DDD可以被多种语言和多种技术框架实现,具体的框架实现需要根据实际的业务场景和需求来制定. 核心的指导思路归纳为: 关注点放在domain上,将业务领域限定在同一上下文中 降低上下文之间的依赖,通过‘开发主机服务’(REST服务是其中的一种).‘消息模式’.‘事件驱动’等架构风格实现 遵循分层架构模式 架构风格 针对DDD的架构设计,<实现领域驱动设计>提到了几种架构风…

本文是基于上一篇‘业务建模小招数’的实践,后面的多篇博文类似.本文主要讲解‘发表帖子’场景的业务建模,包括:业务建模.业务模型.示例代码:示例代码会使用java编写,文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的第一篇,可参考:通过业务系统的重构实践DDD 业务建模 —— Round-I 业务建模 在大家的常识中,每个人都有自己的观点,并可以发表自己的观点,在社区中便表现为:发布帖子.那么谁…

本文是DDD框架实现讲解的第二篇,主要介绍了DDD的Application层的实现,详细讲解了service.assemble的职责和实现.文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的其中一篇,其他可参考:使用领域驱动设计思想实现业务系统 Application层 在DDD设计思想中,Application层主要职责为组装domain层各个组件及基础设施层的公共组件,完成具体的业务服务.A…

本文是DDD框架实现讲解的第三篇,主要介绍了DDD的Domain层的实现,详细讲解了entity.value object.domain event.domain service的职责,以及如何识别出领域中的这些对象,并附有具体的业务建模示例.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的其中一篇,其他可参考:使用领域驱动设计思想实现业务系统. Domain层 Domain层是具体的业务领域层,是发生业务变化最为频繁…

前言 基于 DDD 传统分层架构实现. 项目 github地址:https://github.com/WuMortal/DDDSample 这个分层架构是工作中项目正在使用的分层架构,使用了一段时间发现受益匪浅,所以整理好我对该分层架构的一些理解分享给大家,我对于该分层架构还处于学习阶段理解有误的地方请指出.本次会以一个案例来说明各个分层的作用以及他们之间的调用关系,还有本次的重点不在于DDD,因为这个我还未能完全理解,当然避免不了中间会涉及DDD的一些概念. DDD 简单介绍 DDD 什么?为…

本次分享价值:本次分享主要针对中台.微服务和领域模型的理念.本质及其构建方法论进行探讨.对领域分析的价值所在就是寻求"千变万化"中相对的"稳定性.第一性",然后通过合理的架构分析及抽象隔离业务的复杂度和技术复杂度,隔离业务领域的稳定性和易变性,从架构上精巧.快速的支撑业务的变化. 中台到底是什么? 中台的概念最早是从阿里流传出来的,阿里的中台战略是从业务中台和数据中台开始的,采用业务中台和数据中台相结合的双中台建设模式.后来也有人提出技术中台,AI中台等等. 在阿里…

本文算是<领域驱动设计>这本书的读书笔记,加上自己的一些读后感.网上有很多这本书的读书笔记,但是都是别人的,不如自己总结的理解深刻.建议大家在读这本书时结合<实现领域驱动设计>一起看,同时,一定要去实际建模和编码,理论联系实际才能得其精髓. 定义 DDD是Domain driven design(领域驱动设计)的简称,是一种软件设计和开发的方法论,特别适用于复杂业务领域软件设计和开发.可参考wiki: Domain-driven_design 核心 将所有业务逻辑内聚到业务领域(d…

本文结合团队在ECO(社区服务系统)业务建模过程中的实践经验,总结得到一些DDD业务建模的小招数,不一定是完美的,但是对我们团队来说很有效用,希望能帮到其他人.后面会陆续将项目中业务建模的一些经典例子放上来,分享给大家. ECO系统是线上旧系统,它的建模过程有别于新系统的业务建模.由于背着历史包袱,ECO的建模过程不是那么纯粹,很容易受到旧代码的影响,陷入代码的细节中,初期举步维艰,靠着小步快跑的方式得到了一些雏形和方法论,后面越来越顺,效果还是不错的. 本文为[DDD]系列文章中的其中一篇,其…

在社区系统的DDD实践过程中,将遇到一些问题和产生的想法记录下来,共讨论. 本文为[DDD]系列文章中的其中一篇,其他内容可参考:使用领域驱动设计思想实现业务系统. 1.dto.model和entity之间的互相转化 user interface层的dto.domian层的model.infrastructure层的entity之间的互相转换,比较繁琐,硬编码容易出错. 如果命名较为规范,则可以考虑交给一个公共服务完成自动转换,约定俗成:dto和model为驼峰式命名,entity和数据库表保持…