最近开始筹备一个电商项目. 其实是公司的老本行了. 但今年公司希望在做项目的同时, 沉淀出一套针对电商的基础产品. 这样可以提高新项目的开发效率, 减少重复劳动.
那现如今, DDD(领域驱动设计)应该是比较受推崇的. 所以在这个项目里, 大家决定用DDD来设计系统与抽象业务.
我是十分懵逼的. 只能抓紧时间恶补了.
一开始请教度娘, 看了很多播客, 然而看完之后还是懵逼, 并没有获取到什么有效的知识. 少有的两篇结合能结合实际例子, 上点代码. 然而代码的简易程度也是幼稚的可怜.
这条路看来不行, 那就看书吧. 本想先看大名鼎鼎的<实现领域驱动>, 但鉴于其吓人的厚度, 加上也没从网络上找到电子版资源. 我就先看DDD的开山制作, Eric Evans <领域驱动设计>吧.
因为看的是英文原版, 所以速度较慢.
第一章还没看完, 但我已经感觉有点看不下去了. 因为感觉从开篇到现在,作者强调的东西, 都太空泛了.
比如他强调的'ubiquotus language' 通用语言, 这么高大上的名词, 我真是一点都不懂. 可是看下去才发现, 无非就是说开发人员与业务专家在对于业务理解上很大可能存在不一致, 要消除这种不一致罢了. 我觉得这就属于沟通的艺术的范畴了......
顺便记录几个DDD扯淡专属名词:
1, maps are models : 这句话我很喜欢. map 和model有个共同点, 对现实世界的一种描述与展现.
2,单一职责: OO设计模式老生常谈了.
3,实体Entity: 需要唯一的身份标识
4, 值对象 value_object: 属性相同则认为相同, 只读
5, 领域服务Domain Service: Domain Servcie: 只有方法, 操作,行为, 没有属性和状态.
6, 聚合与聚合根(aggregation &aggregation root)
若干个同类的实体, 值对象 可以聚合, 但这些只能通过聚合根被外界访问.
7, 工厂factory
8, Repository: 数据库交互层
9,CQRS: 查询与命令分离的架构
