Domain Driven Design

时间:2022-09-05 22:52:16

在Spring官网的第一个tutorial中看到了这种 设计模式

Domain Driven Design

找到了篇介绍这个得文章:

What is Domain Driven Design?

"... the key to expert performance in many fields is domain knowledge rather than intelligence." 
Don Reinertsen

Domain Driven Design is a software development methodology, intended to achieve a software system closely modelled on and aligned with real business processes.

Traditionally development tends to be a technically led process, where requirements are passed from the business to the development teams, and then the development teams go off and produce their best guesstimate at what the requirements said.

In a waterfall approach this leads to large requirements documents that are diligently collated, analysed, reviewed and approved. These documents are then given to development teams to turn into working software.

Agile approaches can also accept the requirements documents that waterfall tends to produce, but for them to actually progress forwards they must be broken to small tasks and stories which can then be queued ready for development.

Domain Driven Design to a large degree steps back from these two distinct ends of the spectrum, and looks at how the requirements are gathered in the first place - if you like, it bridges the gap between doing everything up front and everything at the last minute.

DDD understands that requirements are never 'done', but exist as a living document. More importantly, the living document in question is actually the software itself - all other documents are an artefact and reflection of the code.

As the software system develops and grows, deeper understanding of the problem grows too - DDD is all about the discovery of the solution through deeper understanding of the problem.

Where DDD really differs though is that it sees the software system as a reflection of the business process, an enabler rather than the driver. DDD is deeply concerned about the business processes, business terminology and practices. Technical concerns are largely secondary and a means to an end.

The Ubiquitous Language is at the centre of DDD - this is a shared and growing language. A negotiated language derived from the business terminology and enriched by the development teams. If a business person doesn't understand a term in the UL, then the chances are the UL needs an evolution. If a technical person doesn't understand a term in the UL then the chances are they need a conversation with a Domain Expert.

The Domain Experts are the second essential component of DDD - people who deeply understand the business domain, and the business itself. These people are integral to the development process. They may not be required "full time" like the traditional Product Owners of some Agile methodologies, but they must be accessible continually, and be prepared to invest time in the process. Domain Experts are not to be considered outsiders, but as the core of the DDD process - they are as much a part of the development team as any developer or tester.

DDD doesn't begin and end - it is a constant process of re-evaluation, refactoring, remodelling and redesign - every conversation should bring you to a closer understanding of the problem. At no point is DDD 'done' - it is always there; the Ubiquitous Language grows and develops, the Domain Models change as understanding changes, code is restructured and refactored to better represent that understanding.

Artefacts will come and go, but only one really matters - the code base. It is the only expression of the solution that is free of abstraction. While documents may try to explain or describe the system, only the code does so without losing information. This means that in DDD the code must remain of high quality, be clear and expressive, be free of technical abbreviations or jargon, and as far as possible should make at least some sense to a Domain Expert when explained to them.

Clever code doesn't work in DDD, nor do magical processes or "you don't need to know" components. Domain Experts shouldn't need to become developers to understand what the key parts of the software system is doing for them.  They also shouldn't need to think in terms of databases or batch jobs or other technical concerns.

DDD is the ultimate expression of Agile - it is about dealing with a constantly shifting and evolving set of requirements - because as anyone who has ever been involved with a software project knows - it is very rare for a requirement to remain intact from the beginning to the end of a project, and almost impossible for it to do so as the business grows and changes.

Through constant conversations, DDD will guide you to an ever more accurate software representation of your business process.

 

Posted 05-16-2011 3:15 AM by Jak Charlton

over!!!!!!!!!!!!!!!!!!!!!!!!!!!!

原文链接:http://devlicio.us/blogs/casey/archive/2011/05/16/what-is-domain-driven-design.aspx

http://www.oschina.net/news/18245/what-is-domain-driven-design

Domain Driven Design的更多相关文章

  1. 什么是领域驱动设计(Domain Driven Design)?

    本文是从 What is Domain Driven Design? 这篇文章翻译而来. ”…在很多领域,专家的作用体现在他们的专业知识上而不是智力上.“ -- Don Reinertsen 领域驱动 ...

  2. DDD:Strategic Domain Driven Design with Context Mapping

    Introduction Many approaches to object oriented modeling tend not to scale well when the application ...

  3. Domain Driven Design and Development In Practice--转载

    原文地址:http://www.infoq.com/articles/ddd-in-practice Background Domain Driven Design (DDD) is about ma ...

  4. 领域驱动设计(Domain Driven Design)参考架构详解

    摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrast ...

  5. [译文]Domain Driven Design Reference(一)—— 前言

    本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. DDD到目前为止知 ...

  6. &lbrack;译文&rsqb;Domain Driven Design Reference(二)—— 让模型起作用

    本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章 ...

  7. &lbrack;译文&rsqb;Domain Driven Design Reference(三)—— 模型驱动设计的构建模块

    本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章 ...

  8. &lbrack;译文&rsqb;Domain Driven Design Reference(四)—— 柔性设计

    本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章 ...

  9. &lbrack;译文&rsqb;Domain Driven Design Reference(七)—— 大型战略设计结构

    本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 上周末电脑硬盘文件 ...

随机推荐

  1. 数据持久化之NSKeyedArchiver

    基本的数据类型如NSString.NSDictionary.NSArray.NSData.NSNumber等可以用属性列表的方法持久化到.plist 文件中,但如果是一些自定义的类的话,属性列表的方法 ...

  2. command -ubuntu

    WC -c, --bytes print the byte counts -m, --chars print the character counts -l, --lines print the ne ...

  3. iOS-Debug

    1.打印该段代码在哪个类中哪个方法中执行的. NSLog(@"%s",__FUNCTION__); 2.Debug 方法 #define YYLogDebug(fmt, ...) ...

  4. HDU-2031-进制转换

    题目链接 http://acm.hdu.edu.cn/showproblem.php?pid=2031 进制转换 Time Limit: 2000/1000 MS (Java/Others)    M ...

  5. Django rest framework源码分析(3)----节流

    目录 Django rest framework(1)----认证 Django rest framework(2)----权限 Django rest framework(3)----节流 Djan ...

  6. MySQL注射绕过技巧(三)

    在测试一次注入的时候发现过滤了逗号 所以找到这个思路 第一次遇到的时候是看key哥挖洞  遇到后就想记录下来 正文 过滤了逗号  利用join来逐步查询 select*from(select 1)a ...

  7. windows 2008 iis7 上传大文件限制的真正解决办法

    以前做了一个网站 ,当时本机测试时上传文件大小没有问题,上G也应该可以,可是放在服务器后只能上传小于30M以下文件,当时基本需要也基本在30M以下,就没有管,后在网上发现原来是window2008本身 ...

  8. mysql的concat用法

    问题提出:mybatis的mapper文件中的模糊查询: mysql CONCAT()函数用于将多个字符串连接成一个字符串,是最重要的mysql函数之一,下面就将为您详细介绍mysql CONCAT( ...

  9. RocketMq的安装使用

    RocketMq的安装使用 .一.预备环境 1.系统 Windows 2. 环境 JDK1.8.Maven.Git 1.下载 1.1地址:http://rocketmq.apache.org/rele ...

  10. centos7系统优化

    优化说明: 一.关闭selinux 二.更改为阿里yum源 三.提权dm用户可以使用sudo 四.优化ssh远程登录配置 五.设置中文字符集 六.设置时间同步 七.历史记录数及登录超时环境变量设置 八 ...