Co poprawić w tej encji?

Mam taką encję:

public class Post
    {
        public int Id { get; internal set; }

        public string Body { get; private set; }

        public int LikeCount { get; private set; }

        public bool IsAccepted { get; private set; }

        public int TopicId { get; private set; }

        public virtual Topic Topic { get; private set; }

        public string AuthorId { get; private set; }

        public virtual ApplicationUser Author { get; private set; }

        public string AnonymousAuthorName { get; private set; }

        public bool IsRemoved { get; private set; }

        private Post()
        {

        }

        public Post(string body, int topicId, string authorId, string anonymousAuthorName = null)
        {
            Body = body;
            TopicId = topicId;
            AuthorId = authorId;
            AnonymousAuthorName = anonymousAuthorName;
        }

        public void Update(string body)
        {
            Body = body;
            
            // Other editable properties here
        }

        public void Remove()
        {
            IsRemoved = true;
        }

        public void HasBeenAccepted()
        {
            IsAccepted = true;
        }

        public void AcceptanceHasBeenWithdrawn()
        {
            IsAccepted = false;
        }

        public void HasBeenLiked(string userId)
        {
            LikeCount++;
            
            // TODO Create new Like object
        }

        public void LikeHasBeenWithdrawn(string userId)
        {
            LikeCount--;

            // TODO Remove Like object
        }
    }

1. Czy metody modelu nie robią za mało? Czy np. w metodzie HasBeenLiked nie powinienem sprawdzić, czy dany post nie został już polubiony przez danego użytkownika, czy może lepiej umieścić taką walidację w jakimś serwisie?
2. Gdybym chciał dodać, aby autor postu był powiadamiany o tym, że jego post został polubiony, to nowe powiadomienia powinienem tworzyć w metodzie HasBeenLiked, czy w jakimś NotifcationService?
3. Czy w modelu Topic nie powinno być metody tworzącej nowe posty? Czy tworzenie postów po prostu przez konstruktor jest w porządku?

Dlaczego 'hasbeenliked' a nie 'like'?

nie widzę sensu w tych dwóch metodach

public void HasBeenAccepted()
        {
            IsAccepted = true;
        }
 
        public void AcceptanceHasBeenWithdrawn()
        {
            IsAccepted = false;
        }

czy nie właśnie po to masz tą właściwość, żeby można ją było ustawić?

@abrakadaber: Tak by było najprościej, ale nie jestem pewien, czy serwisy mogą tak po prostu operować na właściwościach, jeśli nie tworzę anemicznego modelu. Ale co ja tam wiem, może niech lepiej wypowie się @somekind.

@somekind. Nigdy nie odpowiada na zawołanie.

Robisz sztuczny Rich model. Takie coś wali się prosto do bazy. Widać, że nie czytałeś książki ;#

Jeśli już chcesz to jakoś ubarwiać to podpowiem ci, że w encji post mogła by się znaleźć walidacja posta albo reakcja na zdarzenie, które by zmieniało jego wartość jak np.

void When(PostedToBlog e)

void When(Liked e)

//etc....

Samo tworzenie posta może robić metodą fabrykującą w agregacie jak np. Blog. Ponieważ będzie korzystał z tego samego Id. Mówiąc nomenklaturą DDD — post będzie przyjmował tożsamość bloga.

We wszystkich artykułach, książkach, kursach mówią inaczej. Najlepiej chyba będzie, gdy sobie daruję i będę operował w serwisach na właściwościach. Cokolwiek nie zrobię, i tak będzie źle.
Właściwie to ciekawe, że .NETowcy tak bardzo narzekają na JavaScript i liczbę jego frameworków/bibliotek, a sami nie potrafią opracować jakiejś standardowej architektury aplikacji, która umożliwiałaby jej łatwe skalowanie, a jednocześnie nie była przeinżynierowana. Nie żebym był fanem JSa, po prostu mówię.

nobody01 napisał(a):

1. Czy metody modelu nie robią za mało? Czy np. w metodzie HasBeenLiked nie powinienem sprawdzić, czy dany post nie został już polubiony przez danego użytkownika, czy może lepiej umieścić taką walidację w jakimś serwisie?

Metody, które jedynie ustawiają wartość właściwości to jak dla mnie wciąż ADM.

3. Czy w modelu Topic nie powinno być metody tworzącej nowe posty? Czy tworzenie postów po prostu przez konstruktor jest w porządku?

Ekspertem nie jestem, ale jak dla mnie to wszystkie obiekty tworzą się przez konstruktor.
A jak chcesz mieć metodę fabrykującą, to nie ma sprawy, tylko trzeba mieć powód do tego - np. różne metody obsługujące zupełnie różne sposoby tworzenia postów. No i w takim przypadku konstruktor staje się prywatny.

nobody01 napisał(a):

@abrakadaber: Tak by było najprościej, ale nie jestem pewien, czy serwisy mogą tak po prostu operować na właściwościach, jeśli nie tworzę anemicznego modelu. Ale co ja tam wiem, może niech lepiej wypowie się @somekind.

Jeśli serwisy operują na właściwościach, to chyba zawsze masz anemiczny model.

._. napisał(a):

@somekind. Nigdy nie odpowiada na zawołanie.

Nie odpowiadam głupcom, burakom i innym, którzy przekonali mnie, że nie warto im odpowiadać.

Heh, nie mogę. :|

Nie wiem co tam modelujesz ale moim zdaniem topic to bardzie wartość niż jakiś agregat czy encja.
Agregat to bardziej coś jak np. Discussions, Forum, może blog

Wtedy masz Jakieś normalne metody jak:

Discussion.ModeratePost(moderatorId, Post) //Zamiast LikeHasBeenWithdrawn(wtf)

Nawet forma tego czasownika brzmi dziwnie LikeHasBeenWithdrawn.?

To bardziej brzmi jak reakcja na jakiś event ale dlaczego LikeHasBeenWithdrawn.

To pochwal się jakie to książki przerabiasz o DDD.

nobody01 napisał(a):

We wszystkich artykułach, książkach, kursach mówią inaczej. Najlepiej chyba będzie, gdy sobie daruję i będę operował w serwisach na właściwościach. Cokolwiek nie zrobię, i tak będzie źle.

Właściwie masz rację, fanatycy DDD zawsze znajdą coś, co nie jest zgodne z DDD. A transaction script operujący na modelu danych może być wystarczający do wielu zastosowań.

Właściwie to ciekawe, że .NETowcy tak bardzo narzekają na JavaScript i liczbę jego frameworków/bibliotek, a sami nie potrafią opracować jakiejś standardowej architektury aplikacji, która umożliwiałaby jej łatwe skalowanie, a jednocześnie nie była przeinżynierowana. Nie żebym był fanem JSa, po prostu mówię.

Porównujesz pralkę z lodówką. Frameworki i biblioteki to zupełnie inny temat niż architektura. I w świecie JS też nie ma jednej słusznej standardowej architektury aplikacji. ;]
Nie ma i nie będzie, bo zbyt wiele zależy od konkretnego przypadku żeby dało się cokolwiek uogólnić. Są pewne wzorce, a złożenie ich w działający i ładny system to już zadanie programisty.

Ale ja nie jestem fanatykiem DDD. I nie mam nic przeciwko mieszaniu TS z DDD. DDD to tylko zbiór propozycji projektowych. Jak się bliżej przyjrzysz to zauważysz, że np. Saga, która została opisana w książce Implementing DDD. Jest również w SOA i w świecie JS.