本文讨论了在设计领域对象时如何通过PromotionItem历史记录来确保数据完整性，实现更全面的商品状态追踪，进而支持业务分析需求。通过引入PromotionItemHistory或PromotionItemEvent，捕获商品状态变化，使得数据分析成为可能，同时提供了与事件驱动架构结合的方法，以灵活应对业务需求变化。
转帖：http://xiaoqing.me/2012/01/domain-object-data-integrity/
上一节中，我们介绍了通过createdAt和updatedAt两个字段可以简化领域对象的设计，因为它们捕捉到了最常用的数据，可以简化模型设计。但是常用不代表够用，数据的完整性是任何一个系统必须考虑的。请看：
小明设计了PromotionItem表示促销商品，并知道商品的最新状态和更新时间。春节过后，框框网的促销专区还算可以，不及预想的那么火爆，但是销量比之前上升明显。业务人员想从中做一些数据分析，比如商品从上架到卖出花费多长时间，从而知道哪些类型的商品好卖，以及跟折扣的关系。
这种情况下，小明是没法数据分析的，因为他的建模缺少了历史数据：商品几月几号上架，几月几号下架了，几月几号卖出了。这些实实在在发生过的数据，在PromotionItem一个对象中是很难完整保留的。即使采用之前的onlineTime/offlineTime/expireTime等多个字段也不行，因为商品有可能下架之后重新上架。
所以一旦业务有了新的需求，就无法满足需要。更要命的是，如果系统已经上线，业务再提出这些需求，我们就永远失去了这些历史数据。
这种情况我们叫做丢失了数据的完整性。
此时，我们在建模时，可以给关键领域对象设置关联的历史纪录（或者事件），比如PromotionItemHistory（当然也可以是PromotionItemEvent，一样的思路），把促销商品的每一个状态变化记录下来：
[align=center][img]http://dl.iteye.com/upload/attachment/0072/0787/404095e5-f6ee-3988-a5f3-3f578722abe8.png[/img][/align]
有了历史记录，就可以真正做到“手中有粮，心里不慌”了。这与徐昊在InfoQ上的文章《》其实是类似的思路：通过时标查找重要的领域对象，每个时标都会带来领域对象的变化，而且很多时候是状态的变化，并且把状态变化捕捉下来，以达到数据的完整性。
通过记录状态的变化，可以很容易和基于事件的，或者事件驱动的架构结合起来。比如，业务又来新需求了：每当有产品卖出的时候，业务的头想立刻收到邮件…
这个功能本身不难实现，但考虑到发送邮件不是业务的核心功能，而只是业务支撑，或者业务的增强，我们可以把发送邮件的代码与业务的核心代码分开。怎么分呢，发送邮件的Service可以监听商品的状态发生变化，并适时实现自己的功能，从时序图来说，就是从原来的：
[align=center][img]http://dl.iteye.com/upload/attachment/0072/0789/084b69d2-bbab-3f4b-a3e7-938b13c912a1.png[/img][/align]
替换为下面的实现：
[align=center][img]http://dl.iteye.com/upload/attachment/0072/0791/3c336246-be90-3e65-969c-f0e6e8ef2325.png[/img][/align]
通过修改，把短信和商品的紧耦合编程了松耦合。而且，随着业务量的增大，如果这里出现了性能瓶颈，可以考虑把同步的通知改成异步，甚至可以考虑引入消息中间件——当然，这取决于系统的规模和业务量。
上一节中，我们介绍了通过createdAt和updatedAt两个字段可以简化领域对象的设计，因为它们捕捉到了最常用的数据，可以简化模型设计。但是常用不代表够用，数据的完整性是任何一个系统必须考虑的。请看：
小明设计了PromotionItem表示促销商品，并知道商品的最新状态和更新时间。春节过后，框框网的促销专区还算可以，不及预想的那么火爆，但是销量比之前上升明显。业务人员想从中做一些数据分析，比如商品从上架到卖出花费多长时间，从而知道哪些类型的商品好卖，以及跟折扣的关系。
这种情况下，小明是没法数据分析的，因为他的建模缺少了历史数据：商品几月几号上架，几月几号下架了，几月几号卖出了。这些实实在在发生过的数据，在PromotionItem一个对象中是很难完整保留的。即使采用之前的onlineTime/offlineTime/expireTime等多个字段也不行，因为商品有可能下架之后重新上架。
所以一旦业务有了新的需求，就无法满足需要。更要命的是，如果系统已经上线，业务再提出这些需求，我们就永远失去了这些历史数据。
这种情况我们叫做丢失了数据的完整性。
此时，我们在建模时，可以给关键领域对象设置关联的历史纪录（或者事件），比如PromotionItemHistory（当然也可以是PromotionItemEvent，一样的思路），把促销商品的每一个状态变化记录下来：
[align=center][img]http://dl.iteye.com/upload/attachment/0072/0787/404095e5-f6ee-3988-a5f3-3f578722abe8.png[/img][/align]
有了历史记录，就可以真正做到“手中有粮，心里不慌”了。这与徐昊在InfoQ上的文章《》其实是类似的思路：通过时标查找重要的领域对象，每个时标都会带来领域对象的变化，而且很多时候是状态的变化，并且把状态变化捕捉下来，以达到数据的完整性。
通过记录状态的变化，可以很容易和基于事件的，或者事件驱动的架构结合起来。比如，业务又来新需求了：每当有产品卖出的时候，业务的头想立刻收到邮件…
这个功能本身不难实现，但考虑到发送邮件不是业务的核心功能，而只是业务支撑，或者业务的增强，我们可以把发送邮件的代码与业务的核心代码分开。怎么分呢，发送邮件的Service可以监听商品的状态发生变化，并适时实现自己的功能，从时序图来说，就是从原来的：
[align=center][img]http://dl.iteye.com/upload/attachment/0072/0789/084b69d2-bbab-3f4b-a3e7-938b13c912a1.png[/img][/align]
替换为下面的实现：
[align=center][img]http://dl.iteye.com/upload/attachment/0072/0791/3c336246-be90-3e65-969c-f0e6e8ef2325.png[/img][/align]
通过修改，把短信和商品的紧耦合编程了松耦合。而且，随着业务量的增大，如果这里出现了性能瓶颈，可以考虑把同步的通知改成异步，甚至可以考虑引入消息中间件——当然，这取决于系统的规模和业务量。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
