各位看官司好，领域驱动设计转眼就写到了第十章，内容虽不多，但的确下了一番的心血。希望您在此系列中已经得到了收获，哪怕是一丁点，也是DDD这个圈子的星星之火。其实早就想将自身所学进行一番总结，形成为一种体系化的东西。奈何个人太懒，工作之余就想在床上横着，或刷手机或读书。不过既然下定了决心且已经有了一个开头，那就继续写下去，至少这是对于自己的一种成全。 十几年前我首次接触DDD，将其当成了一门独立的技术去学习，十后之后才发现这个出发点本身就是错误的，早期过于追求战术目标造成后续看待事情过于片面，经过了挫折方知问题所在，所以这个过程是磕磕碰碰过来的。随着个人的成长再加上那一丁点的上进心所驱动，
各位看官司好，领域驱动设计转眼就写到了第十章，内容虽不多，但的确下了一番的心血。希望您在此系列中已经得到了收获，哪怕是一丁点，也是DDD这个圈子的星星之火。其实早就想将自身所学进行一番总结，形成为一种体系化的东西。奈何个人太懒，工作之余就想在床上横着，或刷手机或读书。不过既然下定了决心且已经有了一个开头，那就继续写下去，至少这是对于自己的一种成全。 十几年前我首次接触DDD，将其当成了一门独立的技术去学习，十后之后才发现这个出发点本身就是错误的，早期过于追求战术目标造成后续看待事情过于片面，经过了挫折方知问题所在，所以这个过程是磕磕碰碰过来的。随着个人的成长再加上那一丁点的上进心所驱动，
看到网上讨论DDD的文章越来越多，咱也不能甘于人后啊，以下是我对DDD的个人理解，短小精悍，不喜忽喷。解决什么问题传统模式，产品评审结束，开发人员就凭经验拆分模块，设计数据结构，然后写业务逻辑实现功能。问题在于，不同人的经验、理念不一样，同样的产品需求，最终的技术实现也会不一样；就算是同一个人，可能不同时候接手同样的需求，也会出来不同的设计。究其原因，很多细节之处都是拍脑袋或按个人喜好，或以无所谓的心态处理了，得出的自然是各式各样的结果。往往这些结果是无法令人满意的，这又触发了重构的冲动，然而由于没有一套标准的原则和方法论，所谓的重构只不过是周而复始，盲人探路。DDD(领域驱动设计)的出现，犹
看到网上讨论DDD的文章越来越多，咱也不能甘于人后啊，以下是我对DDD的个人理解，短小精悍，不喜忽喷。解决什么问题传统模式，产品评审结束，开发人员就凭经验拆分模块，设计数据结构，然后写业务逻辑实现功能。问题在于，不同人的经验、理念不一样，同样的产品需求，最终的技术实现也会不一样；就算是同一个人，可能不同时候接手同样的需求，也会出来不同的设计。究其原因，很多细节之处都是拍脑袋或按个人喜好，或以无所谓的心态处理了，得出的自然是各式各样的结果。往往这些结果是无法令人满意的，这又触发了重构的冲动，然而由于没有一套标准的原则和方法论，所谓的重构只不过是周而复始，盲人探路。DDD(领域驱动设计)的出现，犹
我第一次捧起老艾那本《领域驱动设计》，惊为天人。吾辈上下求索数年，这不正是终极之大道吗？结果只三天热乎劲儿，“什么玩意儿”是对这本书的最好评价。好好的一本书让我“弃之如敝履”，差点就“小舟从此逝,江海寄余生”了。几年过后读了网上一些老baby写的吐槽DDD的文章，几乎视其为知音啊，那概括的真是精辟，绝对是个性情爽快的真汉子。借他的花我也献献佛，也说说DDD这点事儿，好好的一门儿学问怎么现在变得神乎其神上升到哲学、玄学的地步，不得不感慨“江山代有才人出”。 上面的图展示了使用DDD的六个困境，相信每一个学习者都会遇到其中的一个两个或多个。 第一层：“本末倒置”，技术人员喜欢将精力放
我第一次捧起老艾那本《领域驱动设计》，惊为天人。吾辈上下求索数年，这不正是终极之大道吗？结果只三天热乎劲儿，“什么玩意儿”是对这本书的最好评价。好好的一本书让我“弃之如敝履”，差点就“小舟从此逝,江海寄余生”了。几年过后读了网上一些老baby写的吐槽DDD的文章，几乎视其为知音啊，那概括的真是精辟，绝对是个性情爽快的真汉子。借他的花我也献献佛，也说说DDD这点事儿，好好的一门儿学问怎么现在变得神乎其神上升到哲学、玄学的地步，不得不感慨“江山代有才人出”。 上面的图展示了使用DDD的六个困境，相信每一个学习者都会遇到其中的一个两个或多个。 第一层：“本末倒置”，技术人员喜欢将精力放
在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。为什么要使用DDD?DDD分为战略部分跟战术部分，相信大家都认同DDD的核心在战略而非战术。而战略方面的核心我认为在业务建模，领域划分、统一语言等都在为业务建模服务。为什么业务建模重要? 以前的开发流程有什么问题？先说结论，开发人员交付的程序对业务方，产品人员，测试人员来说就是一个黑盒子。除了开发人员自己，没人知道盒子里有什么。当新的需求加入来，需求方，产品人员，甚至测试人员都认为可行，开发人员却给出相反结论。回顾一下以前的开发流程大致可以归结为以下步骤：(开发跟测试人员最好能参与需求分析) 1.业
在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。为什么要使用DDD?DDD分为战略部分跟战术部分，相信大家都认同DDD的核心在战略而非战术。而战略方面的核心我认为在业务建模，领域划分、统一语言等都在为业务建模服务。为什么业务建模重要? 以前的开发流程有什么问题？先说结论，开发人员交付的程序对业务方，产品人员，测试人员来说就是一个黑盒子。除了开发人员自己，没人知道盒子里有什么。当新的需求加入来，需求方，产品人员，甚至测试人员都认为可行，开发人员却给出相反结论。回顾一下以前的开发流程大致可以归结为以下步骤：(开发跟测试人员最好能参与需求分析) 1.业
都在IT圈子混，为什么有些人可以成为一流高手，有些人搞了10年研发还只能靠吃老本儿过日子。简单来说，搞这行儿您得勤奋。特喜欢电影《霸王别姬》中的一句：“要想人前显贵，您就得背后受罪”。这人呐，就得学会自已个儿成全自个儿。好多DDD初级玩家上来就特喜欢聊“聚合”啊、“框架”啊、“事件溯源”啊，刘震云先生管这个叫“喷空”。其实他忘了一个重要的事儿：人家之所以能成为高手，那凭得是台下几年的“功夫”，靠得是“悟性”，不是光靠喷空得来的。这个圈子没有傻人，痴人太少。 有些人这辈子也成不了高手，不是不聪明，是“懒”！这个懒包含两面：一是身体上，就喜欢天天躺在床上刷抖音，搞王者荣耀；二是思想上，不愿意
为什么叫“戏说”呢？领域驱动设计出来的时候就有一种对于受众的调戏。书是读完了，您个人升华到了“看山非山，看水非水”的境界。再看一下落地代码，搞不好会仰天长啸：“这是我写的？”。佛家讲“空”，儒家讲“仁”，领域驱动讲“真”。真者，本质也。当您到了“真”的境界，就不会再与别人争论“到底是java还是C#好”，也不会再纠结“我这个设计合不合理啊？”。很多东西自然而然的就出来了。 回顾历史，领域驱动设计（Domain-DrivenDesign，简称DDD）大概源起于2004年。有个洋人叫EricEvans出了本书叫《Domain-DrivenDesign:TacklingComplexityin
