作者回复: 订单可能既是通用中台,又是核心中台,个人感觉订单在电商领域偏通用多一些,它就是一个很常见的公共能力中台。其实还是要看企业的战略,订单对电商企业太常见了,应该不会给企业带来太大的核心竞争力吧,除非这种订单模式是跟其它企业不太一样,而这种能力可以给公司带来非常大的优势。划分核心中台要看你的企业核心竞争力是否在这个领域?
作者回复: 中台是业务概念,很多同类功能的集合。微服务是这些功能的实现。差异还是挺大的。
作者回复: 你说的设计图不知道是指哪类设计图。
DDD似乎还没有什么太好的用于设计的工具,有的话也就是UML之类的工具,很多工具用的也不是特顺手。DDD还缺少一些自动化的代码生成工具以及设计工具,这是它的短板。
我作图一般用visio,费点劲,但是可以自由发挥。
作者回复: 中台是企业级的业务建模。DDD主要解决业务建模和微服务设计的问题。联通核心业务链路,需要在前台设计,让所有的业务环节打通。
划分核心域的主要目的是为了战略投入。很多通用的可能也是核心域。
作者回复: 后面有一节专门讲代码目录。
作者回复: 首先子域是个相对概念,子域可大可小。你需要将中台和子域的维度对齐,这样才会对应。当然会有例外的情况,我这里说的中台主要是业务中台。现在很多中台的概念,比如技术中台、AI中台等,有些地方可能就不好去做对应了。
作者回复: 对需求分析还是有些影响的。
在事件风暴的过程中基本上就大概完成了需求分析的部分内容。在需求分析的文档部分也会有些差异,可能不再是那种长篇大论的需求文档了。一个微服务的需求文档可能是以聚合为单位的面向对象的方式。具体可以结合公司的情况,来慢慢适配。
作者回复: 当然需要的,DDD的战略设计可以跟敏捷更好的结合,具体需要结合企业和团队情况灵活运用。
作者回复: 是的,DDD是一种设计思想,可以同时指导中台领域建模和微服务建设。
作者回复: 中台偏业务多一些,主要考虑复用,微服务这是业务的系统落地,是实现方式,两者还是有差异的。
作者回复: 可以改成通用中台或者核心中台,你有什么建议吗?
作者回复: 谢谢😜,每个图都花了很大的心思来构思的。
作者回复: 是的。里面实体会不一样。
作者回复: 有的。专门一节。
作者回复: 用DDD分层架构啊,四层的。
作者回复: 有些公司资料不方便对外哦。等有时间了,搞个小Demo看看哈。
作者回复: 第11节很快就来了。
作者回复: 可以这么理解。