Haec erit narratio de impressionibus meis libri, et etiam de nonnullis notionibus et cognitionibus, quas per hoc librum didicit,
Architecture
Potesne, hac publicatione legendo, interrogationi clare respondere, quid est architectura? Quid est architectura in contextu programmandi et designandi? Quas partes agit fabula? In hac voce satis multae ambiguitates sunt. Et omnia manifesta esse videntur, sed quodammodo abstracta, et sine certa. Martinus credit, et ei assentior quod applicatio duo habet.
- Morum - munera et munera quae programmata (component, servitium) fungitur.
- Architecture - haec vox magis est de mutanda applicatione.
Sed etiam si applicatio perficit munus quod optime praestare putatur, non tamen significat bene habere architecturam. Architecture non est de applicatione morum. Architectura est fere otium mutationis, architectura est fere otium instruere, architectura est de independentiae evolutionis. Architectura est de velocitate qua intellectus venit ad novum hominem in quadrigis
Et hic est quomodo hanc architecturam construere, quam capitis dolores removere cum parva mutatio est requisitorum ex AM, vel a stakeholder: hoc tibi de libro narrabo.
De auctoribus
Antequam de hoc libro aliquid dicam, pauca de me dicere volo.
In momento Developer Iunior fortis sum, specialiter in evolutione officiorum utens ASP .NET CORE.
Eodem modo "gallery" in anno laboravi, et videtur sicut exiguam rem gerere.
Iam hunc librum 2 times legi, et omnibus eum commendo;
- Tincidunt integer morbi;
- ante-finem fabrum;
- opifices ad-finem;
- et usque ad devos.
In genere, omnibus, qui quoquo modo cum progressione programmatis coniunguntur, directam evolutionem variarum Sales et PMs significamus, hic rationem non consideramus (quamquam utile esset etiam scire cur puellas interdum 2 temporibus impendere. plus temporis molis) moneo ut hunc librum legas.
Nunc autem conabimur argumentari cur ita sentio
Pauca de auctoris huius libri (quia apud me auctoritas scriptoris magnas partes agit). Puto me intelliges, etsi hoc non semper recte, sed si quid auctoritatis in agro tibi dixerit, multo magis confidas in eo quod dixit. Exempli causa, credo te plus credere in diagnosi quod medicus tibi dat quam ex aliquo e turba (qui googled symptomata)
Robert Martin - aka Avunculus Bob (Avunculus Bob) laboravit in campo programmandi et varias rationes (ex officiis interretialibus ad systemata embedit) ab anno 1970 laborata. est technicus consultus et architectus, qui pro variis commentariis technicis scripsit, ipse programmator valde peritus est, et homo qui unum praecipuum munus in creatione notorum solidorum principiorum (si quis creator dicere posset) egit. Etiam addere vellem hunc librum a team plumbo mihi commendatum cum 15+ labore peritia
Circa librum
Dependentiae
Priusquam librum legerem, satis multa capitula in Habre legebam, ubi verbum "addictionis" apparuit. Quid est, qui pendet a quo, quidnam "dependet" significat, et genus ab aliquo quomodo pendere potest?
Et sicut librum legi, duo didici;
Dependentia est terminus qui significat quod aliqua classis (component, servitium) scit de aliquo alio genere (component, service), et haec cognitio in gradu codicis determinata est (nunc Javaists, Sharpists, Sishniks me intelliget) per spatium quoddam importat . Aliis verbis: genus habes A cum spatio nominali Default.Classes et classis B Another.Classes. Ita, si fons codicis ordinis A contineat usus Another.Classes; — Hoc significat genus A ex genere B dependet.
Intelligere ex icone ubi genus dependens est et ubi non est, directionem sagittae vide: in 1) sagitta designabit ex classe A in directione classis B. Hoc significat genus B plus iuris esse quam classis A. Et mutatur in genere A, nulla "damnum" causabitur in genere B
LIQUIDUS
Una praecipuarum rationum quae mihi fuit ut hunc librum legerem solidorum principiorum ab originali fonte explicatio fuit, quia Avunculus Rob haec principia evolvit et, ut diceretur, gratias ei audimus hoc nomen - SOLID.
Nam qui non sunt in scientibus, haec principia loquuntur et suadent ut applicationes tuas ad normam 5 regulae designent;
S - SRP.
O - OCP (Principium apertum)
L - LSP (principium substitutio Liskov)
I - ISP (Principium interface segregationis)
D - DIP (Dependency Inversion principium)
Omnia haec principia applicari possunt ad ordines et res, ad modum modulorum et partium, et ad cancellos.
Si unicum officium principium putas significare genus vel modulum unum tantum facere debere, tunc certe opus est ut saltem caput de Firmo legas. Nam definitio supra posita consequenter est, non autem ipsius principii definitio
De Dependency Inversion
Volumus sedulo in explicatione Principii Inversionis Dependentiae (unum D e SOLIDUM). Cum librum legi, percepi hoc non solum principium esse, etiam mechanismum et instrumentum quo possis directionem mutare clientelas tuas et facere, exempli gratia, negotiationem logicam (DOMAIN) independentem de singulis. Data accessum accumsan exsecutionem (DAL)
Etsi principium ipsum, cum ceteris in SOLIDUM, paulo diversum a mechanismo significat, ipsa mechanismus per totum librum adhibetur, et haec una est ex praecipuis modis ad invertendum et mutandum directionem clientium tuarum, quae; obiter usurpatur in DDD
De iudiciis architecturae faciendis
Saepissime liber commemorabit principium faciendi magni momenti decisiones architecturae: quae datorum utendi, quae compage utendi, quae bibliothecam includendi, quid utendi ut tormenti quaerere, etc.
Sic auctor credit: Decernere debetis QUAM MINUS POTEST. Quia requisita mutare possunt, etiam in perficientur restrictiones, ipsa humanitatis pars ad mutationem tendit. In processu evolutionis, una solutio minus efficax videri potest quam alia, alia minus commoda. Et vis architecturae tuae statuet quam cito et sine dolore unam technologiam cum alia reponere potes (OCP de hoc obiter loquitur).
Exempli gratia, repente, MongoDb loco Postgresql uti statuis, vel lima in genere, vel notitias ludibrium adhibeas, operationes quibus in memoria peragetur. Et sub certis conditionibus, haec omnia fere logica rescribere te cogunt.
Ad eiusmodi condiciones ne oriantur, machinationes nonnullas uti possumus, quae tempus decernendi, quantum fieri potest, repellent. Harum machinarum una est abstractio.
Te ducet ad DDD
DDD - Domain Coactus Design - accessus ad operas explicandas cum multiplici negotio logicae, criticae ad mutationes, quae ad maximizando in- telligentiam consilii administrationis positionum (PMs, Sale administratores etc), cum remigibus ordinariis. Hoc est, ut ubiquitous esset lingua inter omnia membra rei, et quisque alterum intelligere posset, et ut omnes in eadem provincia cum eodem negotio regulas putarent.
Si DDD devotus es, aut unus esse vis, aut aliquid de eo non intelligis, sed intelligere vis, liber legendus est, praesertim secunda pars libri.
Hic auctor exponit existentiam Regulae Dependentiae et cur eius sequendo adiuvaberis ad rectam architecturam applicationis construendam. Cur dependentiae ad componentes High Policy fluere debeant, et cur... domain (Pars Altae Rationis) ab infrastructura independens esse debet et quomodo hoc distributionem et progressionem tuam simplificabit.
Abstractio
Avunculus Rob etiam loquitur quomodo exsequendi singula systema tuum laedere possint ac ne id evolvatur sine dolore in futurum.
Memento!
database exsequendam detail est
Clientes ( Tela , Mobile , etc ) - Exsequendi details
Frameworks are an implementation detail
Opus est ab his omnibus quam maxime abstrahere et ab eo non dependere, uti Dependentia Inversionis supra descriptorum cum interfaces et abstractionibus, Regula Dependentia et aliis mechanismis.
Modi ad aedificationem modules
Maxime probavi hanc sectionem ut elit officiorum in ASP .NET CORE. Quia hic loquimur de methodologiis ad architecturam servitutis aedificandae unitae a praeparatis componentibus.
Robert 4 possibiles tabulas separationis technas describit.
Patet cur tam saepe mechanismum architecturae 3-circuli adhibuerit: UI (magiones), officia (Domain), DAL (Database) satis mala aliis comparata sunt. Plurima incepta non vidi, sed singula, exempli gratia in fine minimum operae, architectura iacuit tribus utitur.
Etiam, saepius, architectura una pars muneris adhibetur. In genere sunt utraque satis bona, sed multum habet incommodis, in comparatione, exempli gratia, quomodo fabricatur architectura cum usura DDD, praesertim cum servitiis criticis et multiplicibus officiis.
Usquam, hic est finis libri huius recensionis. Ipsum librum vere amavi, nec me paenitet legere, auctore auctore. Vobis, dilectissimi lectores, vobis gratias agimus propter attentionem vestram, ne stricte iudicetis - haec editio impressioni libri et personali studio innixa est.
Source: www.habr.com
