Jak rozbijać warstwy w architekturze ściśle warstwowej i promować modułowość bez powodowania zbędnej redundancji?

Otrzymałem zgodę na rozpoczęcie budowy fundamentów pod nową architekturę dla naszej bazy kodów w mojej firmie. Impulsem dla tej inicjatywy jest fakt, że:

• nasza baza kodów ma ponad dziesięć lat i w końcu łamie się w szwach, gdy próbujemy skalować.
Jeśli chcesz je tak nazwać, topowe "warstwy" to bałagan klasycznych ASP i. NET.
• nasza baza danych jest wypełniona bandą bezbożnych przechowywanych proc, które zawierają tysiące linii logika biznesowa i Walidacja.
[14]}wcześniejsi programiści stworzyli "sprytne" rozwiązania, które nie są rozszerzalne, nie nadają się do wielokrotnego użytku i wykazują bardzo oczywiste anty-wzorce; te muszą być wycofane w krótkim czasie.

Odnoszę się do MS Patterns and Practices Architecture Guide dość mocno, ponieważ pracuję nad wstępnym projektem, ale wciąż mam kilka ciągłych pytań, zanim się do czegoś zaangażuję. Zanim przejdę do pytań, oto, co mam do tej pory dla Architektura:

(wysoki poziom)

(warstwy biznesowe i dane w głębi)

Diagramy w zasadzie pokazują, jak mam zamiar podzielić każdą warstwę na wiele zespołów. Więc w tej kandydackiej architekturze, mielibyśmy jedenaście zestawów, nie wliczając w to najwyżej położonych warstw.

Oto podział, z opisem każdego zestawu:

• Company.Project.Common.OperationalManagement: zawiera komponenty implementujące wyjątek obsługa zasad, rejestrowanie, liczniki wydajności, Konfiguracja i śledzenie.
• Company.Project.Common.Security: zawiera komponenty, które wykonują uwierzytelnianie, autoryzację i walidację.
• Company.Project.Common.Communication: zawiera komponenty, które mogą być używane do komunikacji z innymi usługami i aplikacjami (w zasadzie kilka klientów WCF wielokrotnego użytku).
• Company.Project.Business.Interfaces: zawiera interfejsy i klasy abstrakcyjne, które są używane do interakcji z warstwą biznesową z warstw wysokiego poziomu.
• Company.Project.Business.Workflows : Zawiera komponenty i logikę związaną z tworzeniem i utrzymywaniem przepływów pracy w biznesie.
• Company.Project.Business.Components: zawiera komponenty, które zawierają reguły biznesowe i walidację.
• Company.Project.Business.Entities: zawiera obiekty danych, które są reprezentatywne dla podmiotów gospodarczych na wysokim poziomie. Niektóre z nich mogą być unikalne, niektóre mogą być kompozytami utworzonymi z bardziej ziarnistych jednostek danych z warstwy danych.
• Company.Project.Data.Interfaces: zawiera interfejsy i klasy abstrakcyjne, które są używane do interakcji z warstwa dostępu do danych w stylu repozytorium.
• Company.Project.Data.ServiceGateways: zawiera klientów usług i komponenty, które są używane do wywoływania i pobierania danych z zewnętrznych systemów.
• Company.Project.Data.Components: zawiera komponenty używane do komunikacji z bazą danych.
• Company.Project.Data.Entities: zawiera znacznie bardziej szczegółowe podmioty, które reprezentują dane biznesowe na niskim poziomie, nadające się do przechowywania w bazie danych lub innym źródle danych w sposób transakcyjny.

Moim zamiarem jest, aby to powinna być ściśle warstwowa (warstwa może komunikować się tylko z warstwą bezpośrednio pod nią), a modułowy podział warstw powinien sprzyjać wysokiej spójności i luźnemu sprzężeniu. Ale nadal mam pewne obawy. Oto moje pytania, które moim zdaniem są na tyle obiektywne, że są odpowiednie tutaj...

1. Czy moje konwencje nazewnictwa dla każdego modułu i jego odpowiedniego zestawu są zgodne ze standardowymi konwencjami, czy jest inny sposób, w jaki powinienem iść to?
2. czy korzystne jest rozdzielenie warstw biznesowych i danych na wiele zestawów?
3. czy korzystne jest posiadanie interfejsów i klas abstrakcyjnych dla każdej warstwy we własnych złożeniach?
4. najważniejsze - czy korzystne jest posiadanie zestawu "podmiotów" zarówno dla warstwy biznesowej, jak i danych? Moim zmartwieniem jest to, że jeśli włączysz klasy, które będą generowane przez LINQ to SQL wewnątrz komponentów dostępu do danych, to dany encja będzie być reprezentowane w trzech różnych miejscach w bazie kodu. Oczywiście narzędzia takie jak AutoMapper mogą pomóc, ale nadal nie jestem w 100%. Powodem, dla którego je rozbiłem, jest a - egzekwowanie ścisłej architektury warstwowej i B-promowanie luźniejszego sprzężenia między warstwami i zminimalizowanie pękania, gdy nastąpią zmiany w domenie biznesowej za każdym podmiotem. Chciałbym jednak uzyskać wskazówki od ludzi, którzy są bardziej doświadczeni w architekturze niż ja.

Jeśli mógłbym odpowiedzieć na moje pytania lub wskazać mi właściwy kierunek, byłbym bardzo wdzięczny. Dzięki.

Edytuj: Chciałem dodać kilka dodatkowych szczegółów, które wydają się być bardziej istotne po przeczytaniu odpowiedzi pawiana. Tabele bazy danych są również nieświęty bałagan i są quasi-relacyjne, w najlepszym razie. Nie mogę jednak w pełni zrearchitektować bazy danych i wyczyścić danych: najdalej w dół do rdzenia, jaki mogę przejść, to utworzyć nowe przechowywane proc i zacząć deprecjonować stare. Dlatego Skłaniam się do posiadania encji zdefiniowanych wyraźnie w warstwie danych--aby spróbować użyć klas generowanych przez LINQ do SQL (lub jakiegokolwiek innego ORM) jako encji danych po prostu nie wydaje się wykonalne.