Spotkałem się w kodzie z:
ActiveMqAdapter (interfejs) i ActiveMqAdapterImpl.
Trochę dziwne nazewnictwo nie powinno być raczej
np. EventPublisher (interfejs) i ActiveMqEventPublisher (impl) wtedy w domena nie musi wiedzieć, że pod spodem jest jakieś activeMq?
Jakie stosujecie nazewnictwo?
0
3
Pierwsze nazewnictwo, które podałeś nie ma nic wspólnego z portami i adapterami. Bardziej z tym, że Spring wprowadził patologię robienia interfejsu do wszystkiego (bo kiedyś chyba tylko interfejsy można było wstrzykiwać). Stąd te wszystkie "Impl" albo prefix "I" dla intefejsów.
Oczywiście druga opcja jest jak najbardziej ok. Jeszcze pytanie czy domena powinna musi wiedzieć o eventach, czy nie schować tego jeszcze bardziej :) Można eventy zostawić w warstwie aplikacji np. Ale to do decyzji zespołu.
0
Jak chcesz, aby kurczowo trzymać się terminologii z architektury Ports & Adapters to interfejsy to są porty i powinny wtedy się nazywać np. EventPublisherPort (interfejs) i odpowiadający mu ActiveMqAdapter (implementacja).
Ja się nie trzymam tej konwencji i nazywam normalnie (.net here). Czyli w domenie mam IProductRepository (interfejs/secondary port) a implementacja/secondary adapter czyli ProductRepository w projekcie/paczce Persistance.
Kiedyś robiłem też tak, że to czy coś jest Primary Port/Adapter lub Secondary Port/Adapter dawałem w namespace np. MyProduct.Domain.PrimaryPorts, ale się z tego wycofałem.
3
Ja staram się Porty nazywać jakoś domenowo więc np. ten twój EventPublisher pasuje
6
markone_dev napisał(a):
Jak chcesz, aby kurczowo trzymać się terminologii z architektury Ports & Adapters to interfejsy to są porty i powinny wtedy się nazywać np. EventPublisherPort (interfejs) i odpowiadający mu ActiveMqAdapter (implementacja).
Dodawanie suffixów Port i Adapter jest zbędne. Nazwa powinna opisywać odpowiedzialność komponentu.
Ja się nie trzymam tej konwencji i nazywam normalnie (.net here). Czyli w domenie mam IProductRepository (interfejs/secondary port) a implementacja/secondary adapter czyli ProductRepository w projekcie/paczce Persistance.
I co ten przedrostek "I" daje? Domena powinna rozmawiać z ProductRepository, które może być implementowane za pomocą np. MongoProductRepository albo InMemoryProductRepository. Zaproponowane przez Ciebie nazwewnictwo nie niesie żadnych informacji.
5
Jak wyżej - nazwy portów powinny mówić co te porty domenowo robią, a nazwy adapterów szczegół o implementacji, np:
OrdersRepository i PostgresOrdersRepository
CurrencyExchangeRateProvider i RestCurrencyExchangeRateProvider
ArtistInfoProvider i LastFmArtistInfoProvider
Domena i tak nie wie jaka jest implementacja jeśli stosuje się DI (nie mylić z kontenerami IoC)
1
Dodawanie suffixów Port i Adapter jest zbędne. Nazwa powinna opisywać odpowiedzialność komponentu.
Wiem że jest zbędne, napisałem to jako ciekawostkę. Nigdzie nie piszę że tak należy to robić. A ten komentarz wynika z tego, że według niektórych źródeł (Simon Brown, Fowler i inni) kod powinien odpowiadać architekturze i jeżeli na diagramie z architektura mamy jakieś porty i adaptery to prowadzi to do wniosku, że te byty powinny to być odwzorowane w jakiś sposób w kodzie. Inaczej architektura mija się z tym co jest napisane w kodzie.
I co ten przedrostek "I" daje? Domena powinna rozmawiać z ProductRepository, które może być implementowane za pomocą np. MongoProductRepository albo InMemoryProductRepository. Zaproponowane przez Ciebie nazwewnictwo nie niesie żadnych informacji.
Co do przedrostka I dla interfejsów to jest przyjęta taka konwencja w .NET i cały świat dotnetowy tak robi i jest to całkiem normalne wbrew temu co Ty o tym myślisz i co Tobie się wydaje. W innych językach będzie inaczej.