老李一直怀疑自己是不是年纪大了，脑子跟不上了。
作为十几年经验的资深 Java 工程师，维护这公司产品的核心代码的他，现在迭代产品的时候，经常出 Bug 。
有时修复一个 Bug 时间，比开发一个需求的时间要长很多，这是常有的事儿，更可怕的是，改完一个 Bug ，又多出来几个 Bug，让人吐血不止。
这样的情况不在少数，近几次的更新都没有按原计划的时间完成，不但让 Leader 对老李的能力产生怀疑，也让他自己开始怀疑自己。
这是产品迭代到一定时期，必然出现的问题；还是自己年纪大了，在开发时各种问题没有考虑周全，多年的开发经验都不能支撑新的需求。
中年危机加上职业瓶颈，老王觉得自己应该回家修整一下状态了......
废话，改 Bug 的痛苦，每个人都经历过…...
不管是系统维护，还是是在现有系统中进行迭代开发的老司机们，这种痛苦经历，想必你们很熟悉吧：
当需要修改一个 Bug 的时候，面对一个类中成百上千行的代码，没有注释，千奇百怪的方法和变量名字，层层嵌套的方法调用，混乱不堪的结构，不要说准确找到 Bug 所在的位置，就是要清晰知道一段代码究竟是做了什么也非常困难，最终，改对了一个 Bug，却多冒出 N 个新 Bug；
同样的情况，当你拿到一份新的需求，需要在现有系统中添加功能的时候，面对一行行完全过程式的代码，需要使用一个功能时，不知道是应该自己编写，还是应该寻找是否已经存在的方法。
编写一个非常简单的新、删、改功能，却要费尽九牛二虎之力，最终发现，系统存在着太多的重复逻辑，阅读、测试、修改非常困难。
在经历了这些痛苦之后，我们都会发出一个感慨：MDZZ，与其进行系统维护和迭代开发，还不如重新设计开发一个新的系统来得痛快……
改不完的 Bug，是「思想错误」
当你遇到，你应该怎样解决？
面对这一系列让软件陷入无底泥潭的问题，基于面向对象思想的领域驱动设计方法是一个很好的解决方法。
从事过系统设计的富有经验的设计师们，对职责单一原则、信息专家、充血/贫血模型、模型驱动设计这些名词或概念应该不会感到陌生。
我们可以发现领域驱动设计的一大优点：系统高度模块化，代码重用度高，不会出现太多的重复逻辑。
从战略到战术，领域驱动设计（Domain Driven Design，DDD）给出了诸多关于软件架构、设计、建模与编码的方法和模式，以用于应对业务复杂度。
对于学习 DDD 的开发人员而言，第一重要的不是掌握 DDD 的模式，而是要改变分析思维与设计思维的方式。将这种思维方式运用到软件项目开发过程中，就是我所提到的「领域模型驱动设计」，它的核心内容可以通过层层推进的形式汇集为如下三句话：
以领域为分析建模的驱动力
以场景为设计建模的驱动力
以任务为实现建模的驱动力
如何理解这三句话？
当你开始领域模型驱动设计时，必须在分析建模阶段抛开实现技术对你的影响，与需求分析人员、测试人员一起单纯针对「领域」进行分析建模，即提炼与抽象领域概念，并以统一语言和模型的形式来表达。
在设计建模阶段，围绕着一个完整的「场景」开展设计工作。需求分析人员为「场景」编写用户故事；测试人员为「场景」编写验收标准；开发人员则开始解剖「场景」，将其分解为组合任务与原子任务，然后各自分配给不同的角色构造型。
到了实现建模阶段，就针对这些任务定义测试用例，开始测试驱动开发，由内至外到达应用服务时，再将它们集成起来。显然，领域模型驱动设计就是针对领域开展的「合而分分而合」的解构过程。
同时，必须谨记：领域模型驱动设计的基础是限界上下文。在领域驱动设计的战略阶段，同样是一个「合而分分而合」的解构过程：将领域分解为限界上下文，再通过上下文映射联合限界上下文共同实现多个领域场景。
以上内容正是我言犹未尽想要表达的精髓。学习领域驱动设计，就需要抓住 DDD 的根本和精髓。你需要理解什么是限界上下文，它带来的价值是什么；你需要理解如何进行领域建模，统一语言在其中扮演了什么样的角色；你需要理解为何领域驱动设计提倡以领域为驱动力，为何需要领域专家参与到项目开发中来。
提升了对这些内容的认识后，再去学习 DDD 给出的设计模式，学习我给出的固化设计过程，如场景驱动设计。然后找三两个不曾实施 DDD 的项目，寻两三个实施了 DDD 的项目，相互对比其模型与代码，你绝对会有一种醍醐灌顶的感觉。当然，这些都需要你沉下心来细心体会，认真思考，还需要你广泛涉猎更多软件设计与开发的知识，如此方能打通 DDD 的任督二脉。
DDD 不是一门容易衰亡的软件方法学，反而越来越被行业所认可，薪资待遇也是水涨船高超过了大部分平均值。我从 2017 年 11 月写下本专栏的第一个字到现在完成整个专栏，已有两年多的时间了，好在 DDD 在这两年后依然算是一门显学，在微服务与中台光芒的映衬下，DDD 也变得越来越耀眼。
这一路走来，读者们给了我莫大的鼓励。作为全网首个 DDD 专栏，已有超过 5000 位同学订阅学习了。大家每天都在群里进行各种交流分享，毕竟自己闷头学不如群策群力，一起给出解决方案更高效。
如今，专栏终于完成了！《战略篇》一共 34 章，15 万 5 千字；《战术篇》一共 71 章，35 万 1 千字；合计 105 章，共 50 万 6 千余字，加上两篇开篇词与这篇可以称为写后感的后记，共 108 章，算是凑齐了一百单八将。如此成果也足可慰藉我为之付出的两年多艰辛时光！
如果你想从此写代码再也碰不到 Bug
↓↓↓这门专栏非常适合你！↓↓↓
限时特价中
原价 168 元，限时立享 7 折！
↓下单再送 7 门万人订阅的编程课↓
118 元 = 108 章专栏➕7 门赠送编程课➕1V1 答疑➕源码
（迄今为止最划算的订阅时间）
现在订阅你能获得什么？
1. 专业老师陪伴式教学
张逸：曾就职于中兴、惠普、中软国际等公司的高级软件工程师
张逸老师将全程陪你一起吃透每章节内容，不再是你一人闷头去深究那些看不懂的知识点，让你能更高效快速的将所学的内容运用到工作项目中，让你的领导同事大吃一惊。
2. 360度全方位答疑服务
每个专栏都配有多个答疑交流群便于你们提问，老师几乎全程在线解答。群内还会有小助手负责日常整洁，让你在交流学习的同时不受到外界干扰。
3. 额外的福利
你不仅能以 7 折的优惠价格拥有战术➕战略 2 门合订版专栏，现在下单还将免费得到 7 门编程专栏。
如果你想从此写代码再也碰不到 Bug
↓↓↓这门专栏非常适合你！↓↓↓
限时特价中
原价 168 元，限时立享 7 折！
↓下单再送 7 门万人订阅的编程课↓
118 元 = 108 章专栏➕7 门赠送编程课➕1V1 答疑➕源码
（迄今为止最划算的订阅时间）
订阅须知
1. 怎样获取福利？
订阅专栏后可联系小助手「GitChatty6」，回复口令即可快速入群获得。
2. 如何阅读专栏？
本专栏可在 GitChat 服务号、App 及网页端上多端阅读。
3. 专栏内容有多少？
本专栏为图文内容，总共 108 篇课时。
4. 专栏有效期多久？
本专栏一经购买，即可享受永久阅读权限。
点击阅读原文，立即抢购！
