Geek_a91670 置顶2019-10-21事件风暴到底是什么啊?作者回复: 后面章节会有一章专门讲，会有一个案例。跟头脑风暴类似，通过它设计领域模型。
2 4
2019-10-14我能说我等极客时间出这个等了1年吗？编辑回复: 忠实老粉了啊～期待你的打卡！
6 28
2019-12-14面对复杂问题，解决办法通常是拆分，模块化，化整为零。领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。可见领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。DDD战略设计得输出，是微服务的输入。作者回复: 👍高手，每节的总结可以交给你来做了😀。
1 19
2019-10-25我们公司现在也有这方面的想法，但是一直无从下手，主要原因是，
1、我们是给工厂做软件的，不同的工厂相同的功能需求会有有差异，这个怎么解决？显然一个工厂一个版本是不好的
2、不同工厂需要使用不同的数据库
3、功能模块主要有物料管理、订单管理、计划管理、出入库管理、库存管理等，里面功能模块较多
4、DDD怎么更好的去解决SAAS化的产品研发问题作者回复: 第一个问题，我想知道不同工厂软件需求的差异主要在什么地方？如果差异在流程和服务编排，DDD的分层架构应用服务很合适。如果领域层业务逻辑差异不大的话，就比较好解决。个人感觉领域层的核心逻辑差异应该不会大。
第二个问题，DDD数据库方面采用依赖倒置的方式，实现业务逻辑的时候，不会有数据库方面的逻辑，都是领域对象的行为，数据库相关代码在仓储实现中实现。也就是说业务实现与数据库是松耦合的，换数据库的时候，只需要换仓储逻辑就可以了，不会影响核心业务逻辑。
第三方问题，你说的这几个子域相对清晰，直接在子域做事件风暴，建立领域模型，设计微服务就可以了。
第四个问题，见以上三条。总之，保持领域层领域模型的稳定，用应用层去适配外部需求的变化，用户接口层面向不同渠道提供个性数据服务。 2 8
2019-10-15DDD是针对业务的，那么到底怎么理解“业务”呢？什么属于业务，什么不属于业务呢？尤其是业务与技术、基础设施、中间件之间的关系怎么划分？
换句话说，DDD是否适合技术框架、技术平台甚至技术中台的建设呢？比如我要开发一个代码部署系统或者配置管理系统，这样的系统是否适用DDD呢？因为对整个公司来说它们应该属于基础设施层的东西吧。
DDD是否存在大系统套小系统的形式？比如整个公司业务用DDD来设计，然后业务中的某个子系统也用DDD来设计，它们可以嵌套吗？展开作者回复: DDD包括战略设计和战术设计，战略设计主要面向业务完成领域建模，战术设计是根据领域模型完成微服务设计的过程。领域的概念应该包括您所说的代码部署系统或者配置管理系统，只要能在这些领域中能够提炼出领域模型就可以。
4 6
2019-10-14实战源代码，成体系吗？还是散落在文章里面？有的话，哪里可以下载？理论看了很多，缺一套代码，琢磨琢磨。作者回复: 选了一个企业级的中台设计，从领域建模到微服务设计选取了几个典型的中台，过程基本是完整的。最后的示例，源代码只到服务和实体类级别，里面具体业务实现代码没有。也就是说微服务整体架构的框架搭起来，但没有往里填肉。
2 6
2019-10-15这里提到的业务人员是指？还有领域专家。套用公司场景，一个做企业服务，tob的公司，有自己的产品。这个过程中，有客户的需求，有项目经理的梳理客户需求。有产品经理对系统的规划，有客户成功提交的使用优化。这个过程中参与人，客户，项目经理，产品经理，客户成功。人员参与，那这些人在DDD领域模型的角色是？作者回复: 斯图尔特，你好。
领域模型里面都是一些领域对象，这些领域对象是构成系统的一些业务行为。你说的这些角色不知道是不是指系统建设过程中的角色。其实DDD并不改变原来软件开发过程中的角色，只是工作模式发生了变化，大家一起设计领域模型，设计微服务。领域专家是熟悉并深刻理解这个领域的人，可能是业务人员，也可能会是产品经理，甚至可能是开发人员。传统企业一般有信息和业务一说。业务人员一般是指业务部门的人员。 5
2019-10-14我觉得微服务现在转型有个挺大的问题就是团队认识深度。因为现在好多项目都是先简单的以单机项目为基础开发，追求上线速度。后续发现项目越来越大才考虑进行架构方向的整理。导致很有可能出现早期只有开发产品没有架构师参与。这时候转型，架构师多久能吃透现有的业务就是转型速度的瓶颈了。毕竟产品不了解代码，开发人员又往往只盯着自己的模块缺少整体的了解作者回复: 您说的这些问题确实很常见，很多企业都是业务的归业务，技术的归技术。DDD其实也跟中台建设一样，也是一种企业和组织文化的变化，需要业务和技术融合在一起。
5
2019-10-30当然是微服务架构，不是也得跟投资人宣称是
要说最大的问题，就是业务拎不清；让我更进一步分析这种状况，应该是就没有事实上的领域专家，只有很多充其量是熟悉现有业务流程的人，而这些人站在自己的视角阐述问题都没有问题，但是缺少能捏合起来统筹考虑的人，在我们的组织中（我怀疑大多数组织中都是这样），在产品研发团队，关于业务的话语权特别是信息垄断权是掌握在产品（经理）部门手中的，而微服务、DDD的武器却是掌握在技术部门手中，如果技术人员不赶紧学好吃透这些招式，这就对微服务的实际落地，DDD的推广应用，带来了巨大的障碍和困难，我觉得也别无他法，只能忍着被误解和做好顶雷背锅的心态，像Carty说的那样，技术团队中有人挺身而出去承担本该产品经理的责任吧，这样才能给DDD，微服务落地准备足够的营养...我还记得在这个团队在成立初期，产品总监戏称应该定一个组织结构设计架构师的岗位，我估计他主要是说给我这个技术架构师听的，而我只能一脸严肃地表达，确实组织架构应该根据你系统演化的需要来变更的，我就差说你回去好好看看书去不行吗？展开作者回复: 其实你说的这种现象很普遍，很多企业都是业务的归业务，技术的归技术。不容易融合，这也是很多技术难以推行的原因。
4
2019-10-21关于两层边界，聚合虚边界，限界物理实边界，很有启发，也给我一直困惑的，如果一个业务领域中，有多个聚合根的情形下，更加清晰与更好的理解。作者回复: 边界清晰了，以后微服务的演进就相对简单。一般来说聚合内部的功能都是核心的领域逻辑，是一些相对原子化的业务功能，受外部影响比较小。所以在微服务演进时可以以聚合为单元来进行微服务重组。
4
2019-10-16目前公司用的是spring boot 框架，根据业务也做了明显得服务拆分（接单web，调度服务，订单服务，用户服务，资金服务，api服务 等），后期打算把数据层（mysql，mongo，redis）单独拆分出去，web层controller再单独拆分做HA 或者 ng，不知道算不算的上微服务架构，我们在做服务拆分，功能聚合这块是按业务模块来的
问题一：服务的功能界限该如何划定（按功能，还是按业务，有点矛盾）
问题二：服务调用，横向一个个调用，还是按web或者调度中转，比较好？（也存在争议）
问题三：文章中提到界定上下文，请问在服务中该如何体现，不是很明白展开作者回复: 你说的这几个问题我后面都会讲到，耐心等待哈。
第一个问题：会通过事件风暴来建立领域模型。
第二个问题：前后端分离后，可通过API网关调用后端微服务，或者对于复杂的业务场景可以考虑在前端与后端微服务之间增加一个BFF的微服务，可以对多个微服务进行服务组合和编排。
第三个问题：限界上下文边界理论上就是微服务的边界。 4
2019-10-16要进行事件风暴，可以想象是已知信息越多、越全、越准，则越好。
但比如正处于创业初期，存在信息少、未知性多、需求功能少、多领域等情况。
在这样的情况下，老师建议是：
基于现状和不远的以后（比如一年内）来做事件风暴？
还是，尽可能发散到更远的来做事件风暴？作者回复: 你好，刘晓帆。事件风暴对于初创系统的建设是非常合适的。通过事件风暴项目团队可以将所有的可能考虑到，这比一个人思考肯定会更全面更能统一思想。在领域建模和微服务设计时基于现状和不远的将来设计就可以了，但在微服务设计时一定要架构演进的可能，这种架构演进可以很快适应将来的业务发展。如何架构演进，我认为关键在于聚合以及代码边界的设计，在进行功能演进时可以很容易的解耦和进行代码的分离。
3
2019-10-15toB的企业系统，用了微服务，但是还是采用传统的业务流程方式来开发的，感觉都是为了微服务而微服务，希望通过学习后能对DDD有一定的了解，并能对现有的系统进行优化。作者回复: 很多企业刚开始转型微服务的时候可能都有一个这样的过程。由于没有方法指导，还是在按照传统三层架构的模式做微服务，结果只是换了一套支持微服务的技术框架而已。DDD它是一个知识体系，就像一杯好茶，慢慢品，你就能品出其中的味道来。
3
2019-10-15从2016年偶然间发现了springcloud springboot，于是开始带领团队玩起了微服务，在有一些技术积累之后，开始反过来看做过的项目，发现微服务的拆分并没有带来多少好好处，于是今年开始ddd试错。在拆分过程中，个人碰到的几大问题就是
1、数据库彻底拆分之后，带来的编码问题，和多服务调用的性能问题，举个例子，性别代码表，在n多个系统都需要的情况下，如果复制，也数据库没有彻底拆分，或者有冗余，彻底拆分的话，原来关联查询简单的sql，则变成服务之间的调用，可能存在性能问题。比较棘手
2、接触ddd有几个月吧，也在按照这个模式，重新构建项目，只是实体，聚合根在复杂的业务逻辑下，如何拆分和聚合，一直觉得没掌握到位。希望后续案例可以给我启发展开作者回复: 您说的第一个问题，尤其是数据代码类应用场景下都是存在的，这种情况下需要考虑必要的数据冗余，可以采用小表广播的方式，源端数据变了后，可以考虑异步方式广播到数据使用的目的端。
第二个拆分需要考虑限界上下文，并且保证业务的高内聚，高内聚你可以理解为原来的模块的概念，具体大小根据你的业务来定。 3
2019-10-14没有DDD的微服务是没有灵魂的，新瓶装旧酒作者回复: 非常赞同！
3
2019-12-19微服务的关键不在服务的大小，在于边界是否清晰和有效隔离。单体应用向微服务架构演进的第一步是理清系统的领域架构，然后根据领域模型进行重构，每个领域都是“高内聚，低耦合”的模块，这样才能方便后期的拆分。至于服务拆分的大小，哪些需要拆，哪些不需要拆，哪些先拆，哪些后拆，还需要综合考量很多因素，比如团队的组织结构（小团队就不要拆分得太细了），性能，核心功能/非核心功能等等，业务拆分只是其中一小部分，数据拆分才是难点，总之先做好模块化（确定边界，做好隔离）才能实现想拆就拆。作者回复: 是的，单体向微服务架构演进过程中的数据拆分是难点。如果边界清晰就相对容易很多。
2
2019-11-04我之前的公司从legacy单体应用转型为DDD微服务，
最大的问题是：
1. 使用消息队列的过程中，有很多事件不同步、死循环问题。
2. legacy数据库和新数据库的同步。
3. 做reporting的时候，不知道有什么好的招术。作者回复: 第一个问题，不清楚是设计的问题还是消息中间件组件选择的问题。
第二个问题，数据库之间的同步可以采用两种方式，第一种定时扫描源端数据库获取增量数据，但是这种方式会增加数据库的负担和需要单独编写取数代码逻辑。第二种是采用数据库日志捕获技术CDC，但是不知道你这种数据库是否有CDC，如果没有，就不太方便了。
第三个问题，不知道你的报表数据来源，如果是多个微服务，那建议你做一个数据平台，用于汇集各个微服务数据库的数据，所有的报表从这个数据平台获取。 1 2
2019-10-20公司最近也在准备对已有的业务拆分业务领域，希望作者能早点讲实战，对于这块特别是事件风暴方法作者回复: 很快就到了，耐心等待哈。
2
2019-10-15第一个接触ddd的服务是在leader带领下及自己恶补啃ddd砖头书的情况下完成的，收获就是有了点ddd的思想，但是现在对整体和细节都存在理解不清的地方。后面多结合老师的课做回顾和请教~作者回复: 一起学习和进步哈。
2
2019-10-14听说过，一直不知道怎么去实践DDD作者回复: 专栏里面会有详细的过程介绍，先理解概念，然后学会怎么用事件风暴建立领域模型，根据领域模型来设计微服务。等着后面的实战篇哈。
2