思辨领域模型--DDD≠数据库关系模型
Eric Evans的《领域驱动设计》问世已经14年之久,到今天几乎所有业务团队都或多或少有涉及DDD。然而如果较真会发现,认真遵循DDD设计原则的团队仍是少数,在多数团队的现都是:领域模型=数据库关系。DDD崇尚的是oo式表达,也就是常说的充血模型,对以关系型数据库实体关系为中心的关系模型甚至是可以用鄙夷来形容。
数据库关系模型
以数据库关系指导编程实践,是关系对程序的外延入侵,是预假设关系经存在再按图索骥将执行逻辑映射到关系,最终收口是落在数据库而非程序本身。程序本身成了一条条执行通道,每一条通道服务于特定场景的关系,后果必然是过程思维和面条代码。
假设有业务场景--向购物车添加商品,以关系为中心,代码组织如下:
public class CartLine{ @Getter @Setter private String

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
记一次代码重构
单一职责 功能单一 功能单一是SRP最基本要求,也就是你一个类的功能职责要单一,这样内聚性才高。 比如,下面这个参数类,是用来查询网站Buyer信息的,按照SRP,里面就应该放置查询相关的Field就好了。 @Data public class BuyerInfoParam { // Required Param private Long buyerCompanyId; private Long buyerAccountId; private Long callerCompanyId; private Long callerAccountId; private String tenantId; private String bizCode; private String c
- 下一篇
网站常见问题1分钟定位 - 如何使用阿里云ARMS诊断Java应用卡顿问题
不要慌,上面只是一张贴图。 为什么“慢”那么难查 网站卡顿、页面加载过慢是互联网应用最常见的问题之一。排查、解决这类问题通常会花费开发运维人员大量的时间,通常是因为以下三个原因: 应用链路太长,无从下手。 从前端页面到后台网关,从Web应用服务器到后台数据库,任何一个环节的问题都有可能导致请求整体卡顿,到底是前端资源加载过慢?还是数据库出了问题?还是新发布的服务端代码有性能问题?出现问题的原因五花八门。 采用“微服务”架构的应用,链路更加复杂。不同组件可能由不同的团队、人员分别维护,加剧了问题排查的难度。 日志不全或质量欠佳,现场缺失。 应用日志无疑是排查线上问题的神器,但出现问题的位置往往无法预期,发生了问题通常会发现日志信息不全 -- 我们不可能在每一个有可能出现问题的地方打印日志。 “慢”的定义偏主观,“慢”有时候往往也是偶发现象
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS关闭SELinux安全模块
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境
- 设置Eclipse缩进为4个空格,增强代码规范