DDD 在微服务物理设计中的应用_course

DDD（Domain Driven Design）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过 DDD 完成的设计恰恰就是软件的工作方式。 微服务近年来可谓炙手可热，合理的使用微服务架构可以解耦系统，提供更好的软件伸缩性以及提高组织的敏捷性，然而微服务架构从一出来就没有很好的理论支撑如何合理的划分服务边界，人们常常为服务要划分多大而争吵不休。而 DDD 被发现恰好可以弥补微服务的营养不良：通过战略设计可以确定子域并在子域内划分 BC（Bounded Context），一个微服务一般对应一个 BC，同时 BC 内成熟的分层架构和战术设计可以应用在微服务上。 很多团队在微服务内实践 DDD 时，经常会为如何分包而纠结来纠结去，折腾了很长时间也很难满意，同时不同团队，甚至同一团队的不同开发人员的分包原则和方式也大不相同，非常不利于产品代码的开发和维护。我们说的物理设计，主要就是目录和文件设计，可以很好的解决分包问题。 本场 Chat 首先回顾了DDD的基本知识，并将微服务与DDD关联在一起，然后介绍了DDD四层架构模式，为阐述微服务的物理设计打好了必要的基础，接着详细阐述了DDD在微服务物理设计中的应用，并输出了微服务物理设计的推荐方案，以及物理设计经过DCI（Data，Context and Interactive）架构模式、Domain Event建模元素和DIP（Dependency Inversion Principle, DIP）原则驱动后的演进方案，最后列出了作者精心准备的放在github上的多个代码案例，从而有效降低落地难度。希望读者吃透本场 Chat 的知识点，举一反三，灵活应用DDD做好微服务的物理设计，并参考案例代码将其真正落地。 本场 Chat 你将学到以下内容： 1. DDD 四层架构模式 2. 微服务物理设计方案 3. DCI、Domain Event和DIP 驱动物理设计演进 4. 多个代码案例 *当前内容版权归码字科技所有并授权显示，盗版必究。[阅读原文](http://gitbook.cn/gitchat/activity/5b3f43e3c6002d10bd3db970)*

微服务具体工程划分问题_course

微服务最近很多但是对微服务的理解貌似有点不怎么透彻 比如我的项目有用户，订单，积分，消息，商家，商品等这么多模块。如果是单一工程就是很好理解就是一个项目全部都写到里面 那么如果是微服务化的话，我的理解就是把它按照模块分成不同项目，每一个项目都是独立的ssm结构的工程，比如用户(user),订单(order)等等都是单独的独立的完整的一个ssm（mvc三层结构）结构的项目。 然后用户这里需要调用订单也需要调用积分。那就是用dubbo或者spring cloud或者说直接用http来调用就好了。 以前我一直这么理解的。但是最近公司架构师在架构微服务的是好像不是这么回事。 首先架构师还是按照模块分了这么几个项目（分了user,order，message等），但是有个问题就是架构师架构的微服务都是只有service+dao两层结构的工程。然后将springmvc的controller单独抽取出来了。这里可能有UserController,OrderController，成了这种结构了。 到底哪一种是正确的。 感觉spring cloud还是需要一个完整的ssm（三层结构的项目），dubbo好像是我们架构师那种结构（controller是一个工程，service+dao是一个工程）。

领域模型和实体类是什么关系？_course

四处看BLOG，把一部分观点总结起来领域模型贫了血就只剩get/set，这就不是ORM下的实体类吗~~ 可是又感觉不象啊。。。 哪位能给我指点指点那