DDD
文章平均质量分 93
学nm个锤子
Qtmd
展开
-
DDD之领域层设计规范
在一个DDD架构设计中,领域层的设计合理性会直接影响整个架构的代码结构以及应用层、基础设施层的设计。但是领域层设计又是有挑战的任务,特别是在一个业务逻辑相对复杂应用中,每一个业务规则是应该放在Entity、ValueObject 还是 DomainService是值得用心思考的,既要避免未来的扩展性差,又要确保不会过度设计导致复杂性。一,需求背景用代码实现一个龙与魔法的游戏世界的(极简)规则?基础配置如下玩家(Player)可以是战士(Fighter)、法师(Mage)、龙骑(Dragoon)原创 2021-05-02 19:37:59 · 1275 阅读 · 3 评论 -
DDD之Repository模式
一,传统架构下的实体模型传统的应用架构,几乎就是根据需求设计数据库的表,根据表建立实体,对应着实体的就是DAO,Service,Controller,也就是传统的MVC三层架构。回顾下我们平时写的代码,里面有着很多的xxxUtils工具类,很多的参数校验逻辑与业务逻辑混杂在一起,很多的实体类直接与数据库进行一对一映射。好处很明显,在业务初期,开发起来很容易,相对比较简单,流水线式编码,但是,一旦后期需求变更,业务改造,数据库表发生变化,可能给我们带来毁灭性的负担。所谓牵一发而动全身,前面欠下了技术债,原创 2021-05-02 17:18:59 · 2947 阅读 · 1 评论 -
DDD之应用架构
一,前言之所以写这些文章,很大程度上,是因为阅读了阿里技术专家的文章,读完之后,对我内心触动很大,文章多出引用了阿里技术文章的内容,仅作为个人学习用途,也是作为技术人,希望技术可以被更多人学习到。作为一个实习生,谈架构,未免让人感觉,好高骛远,以下陈述只属于个人浅薄意见。依个人浅薄意见,架构的本质就是应用的拆分和聚合。拆分也就是应用微服务化,聚合,并不是指将多个微服务聚合成一个应用,而是指聚合多个微服务的功能,让他完成一个大的功能。这样做的灵活性,可扩展性就会更高。所谓应用架构,个人理解,更可以指原创 2021-05-02 12:31:16 · 1785 阅读 · 3 评论 -
DDD之DP
一,还在用传统业务模型么?1.从一个小需求开始首先提一个小需求,我用传统的编码方式完成它。做一个用户注册系统,同时希望在用户注册后能够通过用户电话(先假设仅限座机)的地域(区号)对业务员发奖金。public class User{ Long UserId; String name; String phone; String address; Long repId;}public class UserService{ private SalesRe原创 2021-05-02 10:56:13 · 1015 阅读 · 2 评论