DDD领域驱动设计今年真的是大火了，这是好事，表明我们的软件开发领域是一直在向前发展的。
但是很多的文章或者培训，都是在说DDD如何如何优秀，简单的举一些例子就行了，有些甚至是完全错误的。
因此笔者决定将自己的实践心得以及与他人讨论的关于DDD的问题整理为一篇文章，通过问题驱动的方式，将领域驱动设计中的一些注意点进行总结，希望能够对读者有所帮助。
主要的问题如下：
事情的经过是这样的，群友四哥发来一个问题，问大家有什么看法，我看了下，刚好之前接触过类似的业务场景，因此斗胆就问题谈谈自己的看法，抛砖引玉。
问题如下：
A系统联机同步调用B系统（A和B不是同一公司系统，不能用分布式事务），
如何保证系统间数据准实时一致性（聊聊设计思路即可）？
提醒：需要考虑调用超时、并发、幂等、反交易先到等。
各种异常场景怎么处理要考虑更完善些，如事务隔离、并发、反交易先到调用方和服务方约定（前端客户不可能一直等着）
本次我们不分享技术，我们来聊聊软素质，具体点说，我们来聊聊新人程序员如何快速熟悉业务逻辑并付诸落地。
一个新人程序员，经历了面试的层层磨炼，终于尘埃落定入职心仪的公司。初来乍到，对周围的一切都不熟悉，业务不熟悉，同事也不熟悉。
这其中关系最大的就是对业务和代码的熟悉，如果能够掌握快速熟悉业务逻辑的方法，就能够很快进入到工作角色中，从容不迫的开展新的工作。
那么我们本次分享就从这几个方面展开：
PS： 由于大部分的开发者都是面向业务，因此本次讨论对于中间件类的开发不做进一步展开，后面有机会再分享。
本文是笔者在一次技术直播过程中的文字大纲，基本上是即兴的，口语化严重。
因此对大纲进行整理，用文字方式进行展现。
既然是“漫谈分库分表”，那么我们需要确定我们要谈什么，不谈什么。
首先，我们不讨论具体的分库分表框架的实现和源码，这不是我们讨论的范围。
我们讨论的是思路，主要讨论如何分库分表的套路，有什么坑，有什么心得，不针对具体的细节进行展开式讨论。当然我自己的能力有限，只是希望能够抛砖引玉。
我们要明确，分库分表，并不是一个银弹，它只是我们针对MySQL单机性能不够的情况下，想要节约成本的一种方式。对于boss来说，既想要想要节约成本，又想要支撑业务，提供稳定持久度性能。
分布式系统开发过程中，我们常常会遇到同时访问多个远程接口，然后在自己的业务逻辑内聚合多个接口的调用结果。这个过程，类比到现实中很像“烧水泡茶”。
在正式讲技术实现之前，我们先以“烧水泡茶”为例，讨论一下并发任务执行在现实中是如何进行的。
烧水泡茶，往往分为如下几步：
这个例子，源自著名数学家华罗庚的《统筹方法》一文，先生试图通过这样一个例子，为我们讲解如何进行统筹，组合不同的步骤，能够在最短的时间内喝到茶水。
那么我们就试着分析一下这个案例，如果我们不加优化，直接通过串行方式进行泡茶工序，那么具体的执行路径就如下图所示：
一直推迟到现在，才逼迫自己打开编辑器，敲下题目。
原本都不计划写年终总结了，总觉得没什么可写。这一年，黑天鹅飞过的一年；这一年，节奏飞快的一年；这一年，与口罩度过最长时光的一年；这一年，也是白驹过隙，充满变化的一年。
妻说，写吧，写了这么多年，而且今年这么特别，等多年以后回头再读，想必会有别样的感悟。我无言。
那就写吧，于2020的末尾，我郑重的写下这个题目，关键词，安好、不易、惊喜。
安好，身边的所有人都安好。
年初的疫情席卷而来，经历了在家办公，经历了严密的管控，安好，都好。
2020，好好活着，就是最大的收获。再也没有比生命更让人值得眷恋。
年纪大了，泪点低了，看着新闻里各个地方的感人事迹，人间英雄，大爱无疆，每次都湿了双眼，然后心怀感恩。
活着，活在这片土地，身为国人而活着，骄傲而自信。
母亲从伤病中恢复，浓密的头发再次茂盛，眼角的笑容又一次绽放，一切安好。
不易，在疫情中换了工作，确实不易，当自己从决定换工作到开始行动，再到最终尘埃落定，只用了5天。妻全程陪伴，给予我全方位的关心和鼓励。因为有她所以我能够一直向前。
来到袋鼠团，我发现我爱上了这个团队，学习型的团队，美团就是一所大学，如果你热爱学习，她会提供各种学习的机会，让你提升，让你去挑战自我。虽然白开水有时候确实不太好喝，嗓子难受，不过这不妨碍我们对她的赞美。
来到一个年轻的，充满激情的，有温度的团队，是我的荣幸。2021年，期待和你们继续披荆斩棘，继续纵情，不断向前。
惊喜，我收到了可以说是前半生最珍贵的礼物，也将会是我付出最大努力去关爱的作品。我即将为人父。
惊喜，又有些紧张，伴随着好奇，我陪着妻，等待着他/她的来临，呵，孩子，我们的孩子，陪你一起成长。
感谢妻，给我一个家庭，让我学着成为一个父亲。
总结是条理的，也是纷乱的，有很多事情想说，但是又觉得不足以与这些并列。
往年总是会对自己一年来学习的东西总结，看了多少书，技术提升了多少。
现在感觉这些都是应该做的，还是简单说说吧。
年末在leader的建议之下，建立了公众号，从此博客成为了文章的备份，也收获了300多粉丝，不算多，但是对我而言，有粉丝在，就是对我的督促，我会在公众号里把自己的工作经验和想法全数分享，倾听别人的意见，收获彼此共同的成长。
加入了一个有温度的技术群，群名也很有朝气和学习气息 “业精于勤荒于嬉”，群里的小伙伴涵盖了70 80 90 00 后，大家为了同一个目标“交流技术，提升能力”聚集在一起，和他们交流已经成为生活中的一部分，公众号中的文章也有来自他们的灵感和付出。2021，我们一起立下flag，继续努力提升自己。
2021，黑天鹅还在盘旋，但生活仍在继续。
保持学习热情，继续提升自己的软硬实力，再让自己平和一些，成熟一些；立个flag吧，万一实现了呢。公众号会继续更新，分布式开发中那些常见的套路，会在2021年更新结束；DDD实战经验系列，也会继续更新；
保护好身体，多陪陪家人，学着做一个合格的父亲，像我父亲一样。
保持思考，要多想，保持质疑，不从众，坚持对的，有原则。努力做一个有温度的人，努力做一个有想法的人。
一切过往，皆为序章，我们的征途是星辰大海。
2021，你好。
写于2021.12.31下午，北京。
学习DDD的时候，作为开发更关心它技术层面的东西，尤其体现在DDD的分包方式、编码技巧等方面。
我们不禁发问，用了DDD的分包，就是实践落地了DDD了么？
不卖关子，直接说答案，并不是。
用了DDD的分包，只能说满足了DDD的形，并没有抓住DDD的神。DDD的神是什么，归根到底还是面向对象，领域建模。所谓的各种分包方式本质上还是为了满足DDD面向对象的本质,方便开发者进行代码编写而提供的一种”战术设计”工具.
要深入讨论这个问题,我们需要花一点时间来学习讨论一下DDD中常见的几种分包。
软件开发领域中，软件复杂度是一个由来已久的话题，从软件的诞生到成熟再到消亡，或多或少总会伴随着软件复杂度的讨论。
我们不禁发问，软件复杂度究竟从何而来？
谈到软件复杂度，有三个话题不得不提及，他们分别是软件规模，软件结构，以及业务的变化。
首先是 软件规模，它涉及到软件本身的代码量，迭代时长以及迭代的次数/数量，以及该软件经手的开发者数量等。这几个要素都会对软件规模造成显著影响，可以回想一下自己接手别人祖传代码时那种忐忑不安、小心翼翼的心态，生怕因为自己的失误导致出现bug甚至背锅的情况；并且代码规模越大，业务逻辑越冗长，这种心态就越发强烈。
今日的后端开发，我们常常听到大家提到“领域驱动设计”、“DDD”等名词，听起来感觉很高端，自己也忍不住想了解，但是又不知从何下手。
不慌，我们这个系列的意义就在于用浅显易懂又不是深度的叙述手法，为大家全方位的介绍普及DDD领域驱动设计的知识，并最终落地到自己的项目中。
那么，我们直接进入正题，领域驱动设计（接下来为叙述方便，用DDD代指）到底是什么？
