领域驱动模型设计的理解

  理解起来很抽象。先看个例子!

 需求： 我要去钓鱼

 我没钓过鱼，那我得去百度， 

  1、买鱼竿鱼钩

  2、找个适合垂钓的场所

  3、选个合适的天气

  4、带上桶，板凳 等辅助工具

  5、理解下钓鱼的真谛，浮子动几下就拉钩子，河里哪里可能容易掉到就去哪里撒香料

  6、本人准备好了就去干！

继续抽象领域：

 1、钓鱼工具

 2、场所

 3、天气

 4、辅助工具

 5、技能

 6、垂钓者

好了,这6个就是钓鱼的主要领域问题。

有了这个领域就可以去知道怎么设计了。

确定业务对象定义、对象间关系、对象名称和对象间关系名称的流程使我们能够以一种能被业务领域专家理解和验证的精确方式来表达业务领域知识

区别于当前大部分程序员得开发

我们现在都是根据需求不断的加代码，  扩展， 迭代， 后期维护非常难， 重构也是很难

领域驱动模型 的设计，能让开发者更好的去思考系统的开发.

摘抄了一篇文章的解释：

我们要开发一个系统时，应该尽量先把领域模型想清楚，然后再开始动手编码，这样的系统后期才会很好维护。但是，很多项目（尤其是互联网项目，为了赶工）都是一开始模型没想清楚，一上来就开始建表写代码，代码写的非常冗余，完全是过程是的思考方式，最后导致系统非常难以维护。而且更糟糕的是，出来混总是要还的，前期的领域模型设计的不好，不够抽象，如果你的系统会长期需要维护和适应业务变化，那后面你一定会遇到各种问题维护上的困难，比如数据结构设计不合理，代码到处冗余，改BUG到处引入新的BUG，新人对这种代码上手困难，等。而那时如果你再想重构模型，那要付出的代价会比一开始重新开发还要大，因为你还要考虑兼容历史的数据，数据迁移，如何平滑发布等各种头疼的问题。所以，就导致我们最后天天加班。