Aplikacja z podziałem na moduły

Odpowiedz Nowy wątek
2019-02-11 11:23
1

Zna ktoś jakąś aplikację open-source podzieloną na moduły? Mówi się na taką architekturę chyba architecture by feature. Chodzi mi o to, że mam np. projekt Modules.Customers i w nim wszystkie związane z klientami DTO, serwisy, komendy, zapytania, handlery itp.

Pozostało 580 znaków

2019-02-11 14:10
1

Tutaj masz całkiem spory projekt. Możesz też spróbować kontrybucji bo community jest dość pomocne.
https://github.com/OrchardCMS

Pozostało 580 znaków

2019-02-11 14:24
1

Cos takiego najlepiej obrazuja aplikacje stosujace Domain Driven Design i/lub oparte o mikroserwisy. Tutaj przyklad sklepu online w oparciu wlasnie o mikroserwisy, z "lekkim" zastosowaniem DDD

Jest to aplikacja przykladowa, z zalaczona darmowa ksiazka ktora warto przeczytac. Warto jednak zaznaczyc ze modularnosc mozna osiagnac bez stosowania mikroserwisow.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-02-11 14:37
0

A jak można by coś takiego osiągnąć bez stosowania mikroserwisów? Myślę o czymś takim:
Api (głównie kontrolery)
Modules:
-Modules.Customers
-Modules.Auth
-Modules.Email
Database (DbContext, konfiguracje mapowań na tabele, migracje)
Infrastructure (klasy niepasujące do pozostałych, np. jakieś extension methods)

Pozostało 580 znaków

2019-02-11 15:05
2

W takim przypadku jest dokladnie tak jak piszesz. Ja bym nie nazywal projektow Modules.X a stosowal pelnoprawne, domenowe nazewnictwo. Chodzi o stosowanie DDD, nawet "lekkie" DDD na mala skale. No ale to moje zdanie. Skoro chcialbys dokonac takiego podzialu, to kazdy modul powinien posiadac swoje wlasne dane -czyli albo oddzielna baza, albo schema na kazdy modul. Teraz kluczem do komunikacji miedzy Twoimi modulami, oraz miedzy kontrolerami a modulami powinno byc zastosowanie command-handler, oraz co za tym idzie CQRS. Mozesz to osiagnac np. stosujac wzorzoec mediator (bilbioteka MediatR lub wlasne rozwiazanie). Wtedy np. kontrolery staja sie "glupie", nie interesuje je co i jak jest wykonywane. Wysylaja jakies polecenie i otrzymuja wynik (lub nie- brak wyjatku moze byc wynikiem poprawnej operacji). Na przyklad:

public IActionResult RegisterCustomer(RegisterCustomerViewModel model)
{
    _mediator.Send(new RegisterCustomer(model.Username, model.Password, model.Email));
   return View(blah);
}

Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 2x, ostatnio: Aventus, 2019-02-11 15:09

Pozostało 580 znaków

2019-02-11 15:16
1

Tu masz aplikację korzystającą z MediatR. https://github.com/JasonGT/NorthwindTraders
Ale nie nazwałbym raczej tego modułami.

Pozostało 580 znaków

2019-02-11 15:19
0
Aventus napisał(a):

Ja bym nie nazywal projektow Modules.X a stosowal pelnoprawne, domenowe nazewnictwo.

Czyli np. MyProject.Customers?

Skoro chcialbys dokonac takiego podzialu

Sugerujesz, że nie warto przy monolitycznej aplikacji? Ogólnie dotychczas używałem podziału zaproponowanego przez @somekind (Api, Application, Contracts, Model) i pisało się przyjemnie. Problem z tym, że czasem trudno jest nawigować po projektach, gdy urosną (tzn. nie mam żadnego dużego projektu, po prostu się domyślam).

kazdy modul powinien posiadac swoje wlasne dane -czyli albo oddzielna baza, albo schema na kazdy modul.

Czyli to oznacza jeden DbContext na moduł?

Teraz kluczem do komunikacji miedzy Twoimi modulami, oraz miedzy kontrolerami a modulami powinno byc zastosowanie command-handler, oraz co za tym idzie CQRS.

MediatR już stosuję ;)

Pozostało 580 znaków

2019-02-11 15:37
1

Czyli np. MyProject.Customers?

Tak.

Sugerujesz, że nie warto przy monolitycznej aplikacji?

Nie, wręcz przeciwnie. Sam aktualnie piszę podobnie rozbitą aplikację.

Czyli to oznacza jeden DbContext na moduł?

To już zależy jak sobie to zaplanujesz. Możesz np. wyabstrahowac repozytoria dla każdego modułu, a mieć jeden kontekst w implementacjach. Przy założeniu że będzie korzystał z jednej bazy danych, logicznie rozbitej na moduły przy użyciu schemas.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-02-11 15:41
0

Jeszcze takie pytanie: czy w tych modułach powinny znajdować się też interfejsy, czy tylko ich implementacje? Jeśli to drugie, to gdzie wrzucić te interfejsy?

edytowany 1x, ostatnio: nobody01, 2019-02-11 15:44

Pozostało 580 znaków

2019-02-11 15:51
1

Jeśli interfejsy są specyficzne dla danego modułu (kontekstu) to w tym module je umieść. Implementacje powinny znajdować się gdzieś indziej, np. w projekcie infrastruktury.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2019-02-11 15:52

Pozostało 580 znaków

2019-02-11 18:41
0

Jeszcze takie pytanie: w którym projekcie powinny być encje? Jeśli umieszczę je w osobnych modułach, to łatwo dostanę cykliczne referencje między projektami.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0