Это правильный путь к модели расширенного домена?

Question

Я занимаюсь рефакторингом своей службы, которая представляет собой автоматическую публикацию в средствах массовой информации, таких как Twitter, Facebook. Интересно, в правильном ли я направлении рефакторинга к "модели богатой области". И если это направление правильное, какие преимущества оно дает?

1. Оригинальная версия.

UML поведенческих объектов, содержащих структуру данных

Это приложение имеет два интерфейса входа и публикации.Проводка"s осуществления имеет статьи иЛогин" s реализация имеет счет. Модель предметной области представляет собой структуру данных (анемичная модель предметной области) в исходной версии. Реализация публикации - это центр логики публикации.

UML Twitter

TwitterPosting.java:

public class TwitterPosting implements Posting,HttpClientTemplateInjectable{

    private Login login;
    private Article article;
    private HttpClientTemplate httpClientTemplate;

    public void setHttpClientTemplate(HttpClientTemplate httpClientTemplate) {
        this.httpClientTemplate = httpClientTemplate;
    }

    @Override
    public void setLogin(Login login) {
        this.login=login;
    }

    @Override
    public void setArticle(Article article) {
        this.article=article;
    }

    @Override
    public ArticlePostingResult post()  
    {
        try {
            
            if(!login.login())
            {
                return new ArticlePostingResult(article.getArticleId(),Status.FAILED,ArticlePostingResult.LOGIN_FAIL_MESSAGE);
            }
            
        } catch (Exception e) {
            return new ArticlePostingResult(article.getArticleId(),Status.ERRORED,ArticlePostingResult.COMMON_ERROR_MESSAGE);
        }
        
        
        try {
            
            HttpResponse response = httpClientTemplate.excute(httpGet("https://twitter.com/twitter").build());
            //Logic posting "article" on Twitter was omitted.


            ArticlePostingResult articlePostingResult = new ArticlePostingResult(article.getArticleId(),Status.SUCCEEDED,ArticlePostingResult.COMMON_SUCCESS_MESSAGE);
            
            return articlePostingResult;
        } catch (Exception e) {
            return new ArticlePostingResult(article.getArticleId(),Status.ERRORED,ArticlePostingResult.COMMON_ERROR_MESSAGE);
        }   
    }
}

2. Рефакторинг версии.

UML модели богатой предметной области

В статье и аккаунте есть публикация и логин. Модель предметной областистатьи является центром логики публикации.

Статья.java:

public class Article 
{
    private long articleId;
    private Media media;
    private Account account;
    private Posting posting;
    private List<String> contents;
    
    public void setPosting(Posting posting)
    {
        this.posting=posting;
    }
    
    public long getArticleId()
    {
        return articleId;
    }
    
    public Media getMedia()
    {
        return media;
    }

        
    public ArticlePostingResult post()
    {
        try {
            
            if(!account.login())
            {
                return new ArticlePostingResult(articleId,Status.FAILED,ArticlePostingResult.LOGIN_FAIL_MESSAGE);
            }
            
        } catch (Exception e) {
            return new ArticlePostingResult(articleId,Status.ERRORED,ArticlePostingResult.COMMON_ERROR_MESSAGE);
        }
        
        try {
            
            PostingResultDto postingResultDto = posting.post(contents);
            ArticlePostingResult articlePostingResult = new ArticlePostingResult(articleId, postingResultDto);  
            return articlePostingResult;
        } catch (Exception e) {
            return new ArticlePostingResult(articleId,Status.ERRORED,ArticlePostingResult.COMMON_ERROR_MESSAGE);
        }   
    }
}

В правильном ли направлении идет мой подход к модели "Rich-Domain-Model" и какие преимущества (с точки зрения инкапсуляции) ожидаются в этом случае?

----------------- дополнительный контент -----------------

Функция приложения
Если пользователи создают статью и планируют ее, мое приложение публикует статью в средствах массовой информации, таких как Facebook, Twitter, количество средств массовой информации превышает 10, и пользователь может устанавливать и изменять определенные расписания, как это,
публикуя "Article1" каждый четверг 10 утра в Facebook.
размещать "Article2" в первый день каждого месяца в Pinterest.
Таким образом, алгоритм публикации, "Публикация", вводится при изменении параметра в версии рефакторинга.

Как создаются статьи?
Собственно у статьи еще два свойства, одно - Media в качестве цели, на которой публикуется статья, другая List<Schedule>Пользователь может устанавливать и сохранять содержимое, мультимедиа, расписание на одном экране, а затем, если пользователи нажимают кнопку " Пуск" на другом экране, запускается автоматическое позирование.

Статья и учетная запись были DTO
Да, в исходной версии, Article и Account это DTO.
Article и Account нет никаких состояний в процессе публикации.
Posting просто возьми Article"S содержание.

в версии с рефакторингом я попытался ввести Posting к Articleне Article к Posting.
Интересно, верен ли мой подход.
в версии с рефакторингом, Articleимеет поведение.
метод postопределяет процесс входа в систему и регистрации.
Если публикация не удалась (ограниченное количество писем и т. Д.), Причины сохраняются в PostingResultDto.
Состояния в процессе публикации (зарегистрированное соединение) поддерживается HttpClientTemplate.
(Я меняю его название на HttpConnection)