Architecture туралы алдыңғы post бірнеше жақсы сұрақ алды, сондықтан оларды бөлек publication ішінде толығырақ талдауды шештім.
Қысқаша қайталау
Негізгі requirements-ты еске түсірейік:
- Application тестпен оңай жабылуы керек.
- Application оңай update болуы керек.
- Code simple болуы керек.
- Data provider оңай ауыстырылуы керек.
- Overall architecture-ға әсер ететін libraries қолданбаған дұрыс.
Бұл requirements practical application-ға бағытталған. Мақсат DDD, CQRS, Event Sourcing және тағы басқа тәсілдерді қатаң ұстану емес.
Архитектураға терең кіретін external libraries-тан неге қашамын
External libraries қолдану әрқашан risk әкеледі. Paid libraries support cost-ты айтарлықтай арттыруы мүмкін. Open-source library авторы оны maintain етуге motivation жоғалтуы, malicious code енгізуі немесе license өзгертуі мүмкін. Library-ді fork жасауға болады, бірақ maintenance burden сізге өтеді.
Егер library application-ның шектеулі бөлігінде ғана қолданылса, бұл әдетте acceptable. Проблема library overall architecture ішіне tightly integrated болғанда пайда болады.
Мұндай libraries boilerplate азайту үшін жиі таңдалады, мысалы reflection қолдану арқылы. Бірақ code lines азаюы better design дегенді білдірмейді. Modern IDEs қазірдің өзінде жақсы completion және navigation береді. Deep framework libraries қолданбау арқылы біз маңызды benefits аламыз: project independence, easier debugging және simpler code navigation.
Үлкен services орнына use-case classes неге ұнайды
Жиі қойылатын сұрақ: неге бірнеше method бар бір service орнына әр action үшін бөлек use-case class жасау керек. Large service басында convenient көрінуі мүмкін, бірақ уақыт өте келе ол ондаған methods және dependencies бар 1000+ lines class-қа айналады. Бұл testing және behavior reasoning процесін қиындатады.
Әр action үшін бір use case сақтау single responsibility, smaller dependency graphs және simpler tests қалыптастырады.
Use cases немесе repositories үшін base classes қолдануға бола ма?
Мен қолданбауды жөн көремін. Base classes-тен inheritance functionality-ді separate service немесе microservice ішіне шығаруды қиындатуы мүмкін. Ол specific behaviors мәжбүрлейді және coupling арттырады.
Мүмкін болғанда inheritance орнына small explicit interfaces және composition қолданған дұрыс.
EF және repository pattern
Кейбір teams EF (Entity Framework) қолдану қосымша abstraction қажет емес деп ойлайды, өйткені ол database-ті онсыз да жасырады. Практикада бұл ORM-ға strong dependency жасайды.
Менің architecture ішінде EF-пен барлық interaction Infrastructure layer ішінде, әр repository implementation ішінде орналасады. Shared base repository қолданбаймын: әр repository explicit және independent.