现在网上有很多讲DDD的文章，但往往一上来就直接讲DDD的某个概念和方法，而且也就是一个孤立的文章和观点，没有体系，如果在没有DDD的实施经验之前，去看这样的文章，会很不明白里面的一些筋筋道道，总会觉得是雾里看花，又是一个有着各种标签的大牛，在甩名词了。
特别是我看到了某个网站上有人有一个DDD的系列网上培训课（付费的），更是把教科书基本上重复了一大遍，让人听的也是摸不着头脑（本人一朋友听本人介绍了DDD后，觉得意犹未尽，网上买来看后观感），听后感觉和听前一样，所以为了解决当下一些朋友对DDD需求，所以才诞生这个系列。
所以在系列开始讲DDD之前，首先我们不是会讨论什么是DDD，而应该是先要搞清楚为什么我需要DDD，只有搞清楚了缘由，各位才清楚，我是为什么而来，需要什么方法和思路，也就是搞清楚我们面临的种种问题，哪些问题可以是DDD来解决的，只有这样，我们才能对其中所涉及到的概念才能切合，才能恍然大悟。我希望能够以实际案例出发，从我本人的思考角度，不光是讲解DDD的一些概念和名词，还要讲这些概念背后的解决的问题是什么，它从何而来，为何而来。要不然依然只能是懵逼的进来，懵逼的出去。
在现今这个时代，越来越多的事物，业务，生活，娱乐，工作流程等都已经信息化。那么伴随着这些业务开始了设计，开发，上线以及持续更新等等，我们会发现在这个过程中我们会面临一系列的问题和一系列的诉求（以下问题和诉求都来自于真实生活和工作，绝不造假：））。
问题一： 业务实际情况 只与 代码一一印证
我曾经待过一个公司，公司中有一个互联网产品已经比较稳定的运行了5年以上了，日交易量很大，业务比较复杂，业务和产品更新的频次也比较多，有一次，公司的产品体验部门负责人找到了我，希望我能帮助他画出整个系统的产品流程和业务流程（说是帮助一起干，其实就是希望我和我的开发干），当时我特别不理解，公司有产品部门呀，有产品文档呀，有业务部门呀，有需求收集书呀，怎么这个活让我们苦逼的开发干，我们开发自己的活已经干不完了，还要帮你们出这么个东西，让我脑中瞬间出现了这个图：
我强忍着怒火，开始和这个负责人一起找各个部门去要这些应该存在的文档，东西都要到了，但发现了一个问题，这些文档要么是过时的，要么不是过时的，但需要找到很多前面的文档做为现有的前提，这个文档才反应真实的产品和业务，而且即便有文档可以确认是最新的，但产品经理依然会补上一句：逻辑和流程还是需要与线上程序逻辑为准！我靠，绕了一圈，这个球还是回到了开发的脚下。听完了这个故事，我来梳理一下这个逻辑：
这个图的大意是：在正常情况下，应该由业务提出需求，产品进行设计，开发设计，开发，测试，上线这样的一个完整的体系，这个是由过程来保证整个体系的产出，但往往现实面临很多的挑战：比如需求的时效性，比如设计的有效性等等，这样挑战的结果往往就导致了有一部分真实的流程是那个红色箭头，这样日积月累，所以只有代码才是真正的业务的反映就不奇怪了。
问题二：开发是一个神秘部门
我曾经接触过这样一个公司，这个公司的CEO是一个业务好手，但是不懂开发（这不是太正常吗），手下有一个技术部门，有一个技术的leader，有一次公司的CEO 无意向我透露了一个看法：不知道这帮技术人员在忙一些啥，很多事情没有人跟进，但开发各个都说在加班，忙不过来，也不知道是不是在划水？ 哇哇哇，虽然这种情况的确有管理不当等其他问题，但我们依然要看到，在外界（公司中除了开发部门），开发部门是整个公司最最神秘的部门，他们很忙，但具体忙的什么，大家不清楚，大家也没提什么高深需求呀，不就是加几个按钮，加了一两个页面吗？这让同为开发的我默默生出一身冷汗。
问题三：业务需要一个秋千，我们最终造了一个....这是什么鬼
这个漫画我印象中是很多年前程序员杂志给出的，给我的冲击和感受特别大，大家可以默默体会一下。
问题四：老板，前面离职的那个技术团队技术太烂了，现在产品根本无法维护，我有一个贼牛逼的框架，可以开始系统重构了！
笔者遇到过多次这种案例，而且在早期的职业生涯，笔者也这么干过。。。。 为什么？原因很简单，你会发现前任的代码要么注释不够，结构混乱，文档缺失（其实大部分不是故意缺失，见问题一），导致我们技术开发必须通过代码，数据库表来反推 产品设计以及业务流程和规则，“我有这个功夫，还不如我自己重新搞一套了”，多么熟悉的话语。所以往往老板被逼得没办法，只得被绑上重构的战车。可以看到这种类型的重构往往最核心的目的不是：为了业务更好的发展，更有效的发展（虽然这些目的也会提及，但都不是最核心的问题），而是为了某些人的熟悉产品和业务的垫脚石，一旦绑上战车，呵呵。所以重构后的技术就有底气去老板办公室：“老板，我要加薪！！！”。。。。。。。。。。。
诉求一：公司能不能只养几个设计人员，编代码的活我都外包？
曾今有一个老板找到了我，这个老板业务能力很强，但业务才刚刚起步，所以成本有限，养不起一个庞大的开发团队，所以希望有人能帮他完成这样一件事：高薪招几个懂开发的人，他们去把设计做出来，然后公司找外包团队再把这个设计去实现，然后再交付给自己的技术团队。其实外包这个办法已经很普遍了，但这里可能会产生几个问题：哪些业务和产品外包；外包后交付的东西是自己业务想要的吗，外包交付的质量如何；外包时如何减少项目的风险；外包交付的东西，如何让公司内部的开发自己能够快速消化？
诉求二：这个项目分析设计后需要30个人月，如果一个人需要干30个月，那公司能不能找30个人来，1个月完活收工？
依然是同一个老板，有一个项目通过一个设计和分析，我们发现其中这个系统一共大概需要30个人月的时间（其实这是成本核算），因为目前公司可投入的开发员工就一个左右，那么大概上可以得出整个项目实施周期在30个月左右，这个时候老板急了，直接说我们能不能找几个外包团队，凑30个人，这样一个月是不是就能完成项目？虽然这个结论比较可笑，但也可以看出，当我们用人月数来做项目成本控制时，很多项目直接领导人会因为周期等原因，会将其进行一些简单的换算，得出一些奇怪的结论。当然我这里不是探讨换算的对和错，但我们也要看到这个结论背后的合理性：当公司现有的自有人员不足已支撑未来的项目时，找来外部团队参与进来，节约时间，这个一定是合理需求。所以我们需要解决的是这么做所面临的挑战：一个较大型的项目，但如何控制好，几个团队对于项目的认知和理解的一致，如何进行任务的划分，如何减少团队间的沟通成本（主要是模块间的依赖）等等问题如何解决。
诉求三：开发干了4-5年了，拿起原型，套着spring框架，立刻就能写代码，但我的未来在哪里，职业规划如何做？5年后的开发模式是什么样的？
很多开发人员干了5年左右，会发现这么一个困惑，就是很多系统和项目都参与过了，但往往最终的实现就是套用spring框架，写着CRUD，这么干未来的出路都是一片茫然。对于未来的发展，我有一个基本的判断：随着openApi的开放越来越多，特别是云计算的到来，saas，paas，iaas等等，感觉越来越多的解决方案层出不穷的出现，在未来，可能我们再讲面对这么一个情况：通用型的服务和模块可以通过服务的模式拿来就用，简单的增删改查已经无法满足与公司的需求（因为简单的，通用的都会用云计算替代）
以上列举了很多场景和诉求，当然也并不是说这些场景和诉求一定是没有用DDD的问题或一定要用DDD来解决的问题，而是想通过这些场景和诉求的描述我们会发现，这里面有一个共性问题：就是在实际的项目设计开发中需求-设计-实现这三个过程往往都是自说自话，根本没有有机的结合（大部分的产品和需求主要关注点是在描述流程或则碎片化的场景），甚至脱节，所以导致以上问题，如果通过一个方法能够保证：需求-设计-实现 这三个线性的过程都能保证准确和一致性，那么以上的问题和诉求都是有可能解决的。那么这个方法在我看来就是通过：DDD。也就是说DDD 是一个用来保证需求-设计-实现相互不脱节的方法（具体为什么脱节，请仔细向上阅读前面描述的场景）
