作者回复: 是这个意思。DDD领域建模优先,领域建模的时基本不考虑数据模型和数据库实现。在微服务具体落地的时候才考虑数据实体的设计。
作者回复: 这一块研究的还不太深入呢。后面我再研究一下。
作者回复: 有什么疑问,咱们可以谈讨哈。
作者回复: 领域建模的目的是为了微服务的设计,领域模型是开始,DDD是一种不同于传统设计的方法 ,先有领域模型,然后才有微服务设计,这样设计的微服务边界很清晰,而不是靠拍脑袋设计微服务。等学完后面全部DDD的内容后,你就知道其中的奥秘了。
作者回复: 走两次就大概知道怎么去做了。理解了理念以后,就不必受一些条条框框的限制了,路是自己慢慢趟出来的,选择最适合自己的方式。
作者回复: 建议你看一下第7节。DDD分层架构:有效降低层与层之间的依赖。里面有详细介绍。
作者回复: 第十八节很详细了呀。
作者回复: 在权限设置的时候,系统会有多个岗位,岗位对应到系统的菜单权限。
作者回复: 传统的需求分析过程大概是这样的:业务人员提出需求-》完成需求分析和设计-》完成系统设计-》开发。。。
需求分析过程中可能也会用到用例分析之类的,但是流程性很明显,主要有需求分析人员完成。
作者回复: 是的。
作者回复: 这样理解就对了。
理解核心理念后,灵活运用。
作者回复: 订阅在应用层,事件的处理属于领域逻辑所以放在领域层。应用服务通过调领域层逻辑来实现。
作者回复: 在权限域吧。
作者回复: 领域模型只是根据业务属性来建立的初步的模型,它的建立过程主要是偏业务多一些,微服务的拆分还需要具体场景具体分析,需要考虑系统的高性能、安全性、版本发布频率是否一致、团队沟通成本等等。每个企业的情况都不一样,不能一概而论。
你的这个分析很好,拆分的时候就是要考虑这些内容。
作者回复: 支付单和物流单的数据是来源于支付和物流域吧。订单域、逆向域和换货域这三个域里的聚合根只是引用支付和物流域的数据吧,订单和支付和物流的数据都是一对一不?如果是一对一,并且需要整体替换,而且不会针对在订单上对支付和物流数据做大量查询统计,你可以将支付和物流的数据设计为订单聚合根的值对象,如果这几不满足,你将它们设计为订单聚合根的引用实体也行。不需要在订单业务中,再设计支付单域和物流单域。
作者回复: 不理解你为什么做了微服务还要放在单体里面运行呢?
是因为没有容器这些云平台吗?还是为了整体运维和与原来的单体集成方便?
其实你可以将它部署为单独的微服务,然后暴露接口给原来的单体应用,中间做一个接口的协议转换就可以了,如果两者业务逻辑上有差异,需要适配的话,你也可以加一层防腐层代码,避免污染领域模型。
作者回复: 其实两者都是建立企业级的业务架构的策略,自顶向下主要从业务角度出发,而自底向上呢主要从业务和系统现状出发,考虑现有系统情况会更多一些。虽然领域建模时都是在一个小的业务域内,但是最后都还有一个模型查重的过程,以解决模型跨域重复的问题。
作者回复: 在分析的时候,会分析出修改配置项的命令的,这个命令会对配置项实体操作,可能对应到一个应用服务。而这个实体初始化的数据可能来源于数据库配置,或者配置中心,或者文件。