The DDD model has gone from esoteric to practical

background

DDD introduced

DDD history

Relationship between DDD and microservices

1. Feature dimension
2. Quality dimensions (including performance and availability)
3. The engineering dimension

The architecture of a system is defined by the architectural boundaries within the system and the dependencies between those boundaries, regardless of how components in the system are invoked. The so-called service itself is just a form of partitioning application behavior that is slightly more expensive than function calls, regardless of system architecture.

1. C Independent deployment: Resources are properly tilted to expand or shrink capacity independently.
2. Elastic service: retry, fusing, degradation, etc., has reached fault isolation.
3. Technology stack independence: C can be written in other languages, making it more suitable for personalized team technology stacks.
4. Team independence: Different teams can be responsible for it.

• First, aggregate root to ensure the correctness of internal entity rules and data consistency;
• Second, external objects can only refer to the aggregate root by id, not entities inside the aggregate root.
• Third, aggregation roots cannot share a database transaction with each other, and data consistency between them needs to be guaranteed through final consistency.

DDD related terms and basic concepts

field

subdomain

The core domain

General domain

Support domain

A unified language

Bounded context

The aggregation

1. What information must exist within an aggregation boundary, without which it cannot be called an effective aggregation;
2. The state of some objects within the aggregation must satisfy a business rule:

• An aggregate has only one aggregate root, which can exist independently and other entities or value objects in the aggregate depend on the aggregate root.
• Only the aggregate root, which maintains the internal consistency of the aggregate, is externally accessible.

Aggregate root

entity

The value object

1. Blood loss model
2. Anemia model
3. Congestion model
4. Expanding blood model

background

public class Article implements Serializable {
    private Integer id;
    private String title;
    private Integer classId;
    private Integer authorId;
    private String authorName;
    private String content;
    private Date pubDate;
    //getter/setter/toString
}Copy the code

public interface ArticleDao extends BaseDao<Article>{
    //...
}

Repository("articleDao")
public class ArticleDaoImpl implements ArticleDao{
    //...
}Copy the code

public interface ArticleService extends BaseService<Article>{
    //...
}

@Service(value="articleService")
public class ArticleServiceImpl implements ArticleService {
    //...
}Copy the code

Four pattern examples

Blood loss model

public class Article implements Serializable {
    private Integer id;
    private String title;
    private Integer classId;
    private Integer authorId;
    private String authorName;
    private String content;
    private Date pubDate;
    //getter/setter/toString
}

public interface ArticleDao {
     public Article getArticleById(Integer id);
     public Article findAll();
     public void updateArticle(Article article);
}Copy the code

Anemia model

public class Article implements Serializable { private Integer id; private String title; private Integer classId; private Integer authorId; private String authorName; private String content; private Date pubDate; Public Boolean isHotClass(Article Article){//getter/setter/toStringreturnStream of (57102). AnyMatch (every - > every. Equals (article. GetClassId ())); } public Article changeClass(Article Article, ArticleClass ac){return article.setClassId(ac.getId());
    }
}

@Repository("articleDao")
public class ArticleDaoImpl implements ArticleDao{
    @Resource
    private ArticleDao articleDao;
    public void changeClass(Article article, ArticleClass ac){
        article.changeClass(article, ac);
        articleDao.update(article)
    }
}Copy the code

• The parts of the Domain Object that are more closely dependent on persistent Domain Logic are separated into the Service layer and are not OO enough
• The Service layer is too thick

Congestion model

Service (transaction Encapsulation) — > Domain Object < — > DAO

public class Article implements Serializable { @Resource private static ArticleDao articleDao; private Integer id; private String title; private Integer classId; private Integer authorId; private String authorName; private String content; private Date pubDate; //getter/setter/toString // public List<Article>findAll() {returnarticleDao.findAll(); } public Boolean isHotClass(Article Article){public Boolean isHotClass(Article Article){returnStream of (57102). AnyMatch (every - > every. Equals (article. GetClassId ())); } public Article changeClass(Article Article, ArticleClass ac){returnarticle.setClassId(ac.getId()); }}Copy the code

• More aligned with OO principles;
• The Service layer is thin and acts as a Facade rather than a DAO.

• Daos and Domain Objects form bidirectional dependencies, and complex bidirectional dependencies can lead to many potential problems.
• The division of Service layer logic and Domain layer logic can be very ambiguous, and in real projects, the overall structure can be chaotic due to differences in the level of designers and developers.

Expanding blood model

Domain Object (Transaction Encapsulation, Business Logic) < — > DAO

• Simplified layering
• It’s also OO

• Many Service logics that are not Domain Logic are also forced into Domain Object, which causes the instability of Domain Object model.
• Domain Objects expose too much information to the Web layer, which can cause unexpected side effects.

Practice of using DDD to transform existing old system

The perfect combination of DDD and the Spring family

Module

import com.company.team.bussiness.counter.*; / / count the context import com.com pany. Team. Bussiness. Category. *; / / classification context import com.company.team.bussiness.com ment. *; // Comment on contextCopy the code

import com.company.team.bussiness.cms.domain.valobj.*; / / domain objects - value objects import pany. Com.com team. Bussiness. CMS. Domain. The entity. *; / / domain objects - the import entity com.com pany. Team. The bussiness. CMS. Domain. Aggregate. *; / / root domain objects - polymerization import pany. Com.com team. Bussiness. CMS. Service. *; / / field service import com.com pany. Team. Bussiness. CMS. Repo. *; / / field repository import com.com pany. Team. Bussiness. CMS. The facade. *; // Field anticorrosion coatingCopy the code

Domain object

package com.company.team.bussiness.domain.aggregate; import ... ; public class Article { @Resource private CategoryRepository categoryRepository; private int articleId; // article id... private ArticleCount articleCount; // getters & setters // query counts display quantity, this is a bit of a simple logic, even does not fit the actual business scenario, this is not important, just for the purpose of intuitiongetShowArticleCount() {
            if(this.articleCount == null){
            return 0;
        }
        returnthis.articleCount.realCount + categoryRepository.getCategoryWeight(this.category) + (this.articleCount.adCount * DayUtils.calDaysByNow(this.articleCount.deadDays)); }}Copy the code

The repository

import com.company.team.bussiness.repo.dao.ArticleDao; / / database access object - article import com.company.team.bussiness.repo.dao.Com mentDao; / / database access object - comment on import com.com pany. Team. The bussiness. Repo. Dao. Po. ArticlePO; / / database persistent object - article import com.company.team.bussiness.repo.dao.po.Com mentPO; / / database persistent objects - comment on import com.com pany. Team. Bussiness. Repo. Cache. ArticleObj; // Distributed cache access object - article cache accessCopy the code

package com.company.team.bussiness.repo; import ... ; @Repository public class ArticleRepository { @Autowired private ArticleDao articleDao; @AutoWired private articleDaoCacheAccessObj articleCacheAccessObj; public Article getArticleById(int articleId) { Article article = articleCacheAccessObj.get(articleId);if(article! =null){return article;
        }
        article = getArticleFromDB(articleId);
        articleCacheAccessObj.add(articleId, article);
        return article;
    }

    private Article getArticleFromDB(int articleId) {...}
}Copy the code

Anticorrosive coating

• Models in external context need to be translated into models understood by the context.
• For the team collaboration between different contexts, if it is an enshrine relationship, it is recommended to introduce an anti-corrosion layer to avoid the erosion of the local context by external context changes.
• This access is used extensively in this context to avoid overreaching changes.

package com.company.team.bussiness.facade; import ... ; @Component public class ArticleFacade { @Resource private ArticleService articleService; public Article getArticle(ArticleContext context) { ArticleResponse resp = articleService.getArticle(context.getArticleId());return buildArticle(resp);
    }

    private Article buildArticle(ArticleResponse resp) {...}
}Copy the code

Field service

package com.company.team.bussiness.service.impl import ... ; @Service public class CommentServiceImpl implements CommentService { @Resource private CommentFacade commentFacade; @Resource private ArticleRepository articleRepo; @Resource private ArticleService articleService; @Override public CommentResponse commentArticle(CommentContext commentContext) { Article article = articleRepo.getArticleById(commentContext.getArticleId()); // Get the article aggregate root Commentfacade.docomment (commentContext); // Add count informationreturnbuildCommentResponse(commentContext,article); } private CommentResponse buildCommentResponse(CommentContext CommentContext, Article Article) {... }}Copy the code

Demonstration package structure