领域驱动设计中把术语在不同领域中的差异提到了比较高的程度。这其实是日常工作中非常常见的问题，同一个名词，不同人的理解是不同的，在不同业务中的含义也不同。最近正在构建组织架构服务，不同人想的就不一样。行政/HR想的是在企业IM里看到的是组织架构，实际上是按业务线划分。财务想的是，凭证进财务系统的时候，需要按照不同公司，这又是一个组织架构。业务团队之间会产生协作，比如都是为用户增长，参与协作的人又会形成某种组织架构。

在限界上下文中统一术语的认识，而不是花更多精力让所有参与者都统一术语，其实是非常务实的做法

这篇真的太棒了！正如微服务里的两句话“微服务是双刃剑，拆得越细，优势越明显，缺点也越明显”，“要用好微服务，最好别做微服务”。深刻了！

感触很深，之前我们在开发一个新项目中，3个人拆了10+个微服务，维护、排查问题都很麻烦；之后服务减少到3个才好很多；微服务很好，但是我们要明白为什么要微服务，以及微服务会带来哪些问题，千万不要一上来就微服务。 血淋淋的教训！

我是今年年初的时候接触到领域驱动设计的，看Eric的《领域驱动设计》确实给了我非常大的启发，给我目前工作中遇到的问题指明了方向。DDD改变了我思考问题的方式，让我把关注点回归业务，而不是一开始就去考虑技术的是实现问题。尤其是限界上下文的概念，让我明白了一直在搞，却总是搞不好的微服务到底是哪儿出了问题。
但是目前的困境是：想在公司内推行DDD，阻力真的很大，首先是很多人对DDD没概念，需要一定的学习成本，二是团队间相互隔离，沟通成本很高，起码的通用语言都很难达成。在上次迭代中，很多时间都花在弥补因为沟通不畅导致的扯皮中了，最后就是功能虽然实现了，代码却早已经改成了大泥球。还有就是不顾长远的赶进度，实现功能是首要的，领域模型就成了没有人去做，也没有时间去做事情。

说的好，领域驱动设计确实是进入微服务的前置条件，除了设置边界上下文，还要划分子域，实现领域驱动设计那本书看了后，其实还是要看一下Eric的那本书，一个是道，一个是术。

老师有没有计划开辟一个专讲ddd的专栏

一个很重要的点是, 即便没有DDD的概念, 我们自己的系统也一定需要有自己的业务模型, 任何需求的变化一定都是需要在这个业务模型上最先体现变化出来, 外部和我们系统的交互, 一定是先翻译转换为我们自己的内部模型, 然后再进行逻辑处理, 否则外部依赖源一旦增多, 很多转换会把整个系统代码污染到不想再维护的

"什么，讲了这么多，让我不用微服务?"
"及时止损"对很多人来说，是不可接受的。

公司说我们的开发方式是敏捷开发，实际上只是使用了一些敏捷开发的方法，只有遵守敏捷开发的价值观和原则，才能算是敏捷开发。微服务也是一样，不是说拆分成多个服务去部署，就叫做微服务。也不是采用市面上常用的微服务框架，就是微服务了。

老师说的很有道理，我们经常会忽视基本面去谈理想和目标。DDD是一套思维体系，虽然市面上有很好的资料给予我们借鉴，但怎么去定义自己的领域、子域的边界及彼此的交互关联不一而足。周围也有人为微服务而微服务，真要是落在纸面上却无从入手，背后是抽象能力还不足以支撑期望。另一方面是避免过度设计，就如上讲所说淘宝也是演进来的，DDD也不是一步到位的，需求在变要求在变，设计也就需要跟着变。总的说来我觉得就是需要提升抽象能力和做好持续改进的准备，不能操之过急也不能局限于眼下。

不错的文章，期待后面更多DDD方面的实践例子。
实际工作中很常见到的是做微服务了，但很时候微服务没有很好的模块化，结果还是往big ball of mud的方向写。

如果是使用hibernate ，实施起DDD，会容易一些。但是互联网公司大部分用mybatis，毕竟sql得完全自己控制才好。

郑老师，有个问题请教下:微服务应该不应该共享一个所谓的公共二方库common。比如一些枚举类，工具类，DTO类放入这个common库中。如果用common类，那么就增加了服务之间的耦合度，如果不使用，那么又会出现同一个类重复定义的问题。

DDD 是一本武林秘籍,屠龙宝刀,分场合使用

做为一个运维，表示没看懂😭 看来离程序员还有一段很长的距离……

多谢老师推荐书单。
之前使用过DDD的防腐层设计，为了减少模块之间的耦合，隔离变化。其他概念还需要深入学习，并在实际项目中实践。