Clean Architecture ja Onion Architecture ohjelmoinnissa

Tämä blogikirjoitus syventyy ohjelmoinnissa Clean-arkkitehtuurin periaatteisiin. Vastatessaan kysymykseen "Mikä on Clean Architecture?", se käsittelee sen etuja ja vertaa sitä Onion Architectureen. Kerrokset ja roolit selitetään yksityiskohtaisesti, ja käydään läpi parhaita käytäntöjä Clean-arkkitehtuurin käytössä. Lisäksi korostetaan Clean- ja Onion-arkkitehtuurien yhteisiä piirteitä. Joycen M. Ononen näkökulman rikastama sisältö arvioi myös vaikutuksia suorituskykyyn. Kirjoitus päättyy visiolla Clean-arkkitehtuurin tulevaisuudesta, jota tukevat suositellut lähteet ja lukulista.

Mikä on Clean Architecture ohjelmoinnissa?

Sisältöhakemisto

Clean Architecture on ohjelmistokehitysfilosofia, joka pyrkii lisäämään kestävyyttä, testattavuutta ja riippumattomuutta ohjelmointiprojekteissa. Robert C. Martin (Uncle Bob) esitteli tämän arkkitehtuurin lähestymistavan, joka minimoi erilaisia riippuvuuksia erilaisten kerrosten välillä järjestelmässä varmistaakseen liiketoimintasääntöjen ja perustan kehittämisen ilman ulkoisia vaikutuksia (käyttöliittymä, tietokanta, kehykset jne.). Tarkoituksena on varmistaa ohjelmiston pitkäikäisyys ja kyky sopeutua muuttuviin vaatimuksiin helposti.

Mikä on Clean Architecture ohjelmoinnissa?
Ominaisuus	Kuvaus	Edut
Riippumattomuus	Riippuvuuksien vähentäminen kerrosten välillä.	Muutokset eivät vaikuta muihin kerroksiin.
Testattavuus	Jokaisen kerroksen on oltava testattavissa erikseen.	Nopeat ja luotettavat testiprosessit.
Kestävyys	Ohjelmiston pitkäikäisyys ja helppo päivittäminen.	Alhaiset ylläpitokustannukset.
Joustavuus	Helppo sopeutuminen erilaisiin teknologioihin ja vaatimuksiin.	Nopea kehitys ja innovaatio.

Clean Architecture perustuu kerrokselliseen rakenteeseen, jossa tärkein periaate on riippuvuuksien suunta. Toisin sanoen, ulommat kerrokset (käyttöliittymä, infrastruktuuri) voivat olla riippuvaisia sisemmistä kerroksista (liiketoimintasäännöt), mutta sisäkerrokset eivät saisi olla tietoisia ulomista kerroksista. Tämä suojaa liiketoimintasääntöjä ja perustan ulkoisten muutosten vaikutuksilta.

Clean Architecture:n peruselementit

Riippuvuuksien kääntöperiaate (Dependency Inversion Principle): Korkean tason moduulien ei pitäisi olla riippuvaisia matalan tason moduuleista. Molempien tulisi perustua abstrahointiin.
Yhden vastuun periaate (Single Responsibility Principle): Luokalla tai moduulilla tulisi olla vain yksi vastuu.
Rajapinnan jakamisen periaate (Interface Segregation Principle): Asiakkaiden ei tulisi olla riippuvaisia metodeista, joita he eivät käytä.
Avoimuuden ja sulkemisen periaate (Open/Closed Principle): Ohjelmistoresurssit (luokat, moduulit, toiminnot jne.) tulisi olla laajennettavissa, mutta niitä ei pitäisi muuttaa.
Yhteiskäyttöisyyden periaate (Common Reuse Principle): Paketin sisällä olevien luokkien tulisi olla uudelleenkäytettävissä yhdessä.

Clean Architecture pyrkii vähentämään ohjelmistokehitysprosessin monimutkaisuutta, luoden helpommin ymmärrettäviä, helposti hoidettavia ja testattavia sovelluksia. Tämä arkkitehtuuri on erityisen tärkeä suurissa ja monimutkaisissa projekteissa, ja sillä on merkittävä rooli pitkäaikaisessa menestyksessä. Perusperiaatteiden noudattaminen parantaa ohjelmiston joustavuutta ja sopeutumiskykyä, mikä auttaa valmistautumaan tuleviin muutoksiin.

Clean Architecture ohjelmoinnissa on suunnittelulähestymistapa, joka tekee ohjelmistoprojekteista kestävämpiä, testattavampia ja riippumattomampia. Riippuvuuksien hallinta kerrosten välillä, liiketoimintasääntöjen suojaaminen ja SOLID-periaatteiden noudattaminen ovat tämän arkkitehtuurin perusta. Tämä mahdollistaa ohjelmistokehitystiimien tehokkaamman toiminnan ja projektien pitkäaikaisen menestyksen varmistamisen.

Clean Architecture:n edut

Clean Architecture ohjelmoinnissa tarjoaa kehitysprojekteille monia etuja. Tämä arkkitehtuurinen lähestymistapa parantaa koodin luettavuutta, helpottaa testattavuutta ja alentaa ylläpitokustannuksia. Riippumattomien kerrosten ansiosta muutokset järjestelmässä eivät vaikuta muihin alueisiin, mikä nopeuttaa kehitysprosessia ja vähentää riskejä.

Clean Architecture:n edut
Etäisyys	Kuvaus	Vaikutusalue
Riippumattomuus	Kerrosten välinen riippumattomuus, muutokset eivät vaikuta muihin kerroksiin.	Kehitysnopeus, riskin vähentäminen
Testattavuus	Jokainen kerros voidaan testata erikseen, mikä lisää luotettavuutta.	Laatutakuu, virheiden vähentäminen
Luettavuus	Koodin ymmärtäminen on helppoa, mikä nopeuttaa uusien kehittäjien sopeutumista projektiin.	Tiimitehokkuus, koulutuskustannukset
Kestävyys	Koodin ylläpito on helppoa, mikä vähentää pitkän aikavälin kustannuksia.	Kustannussäästöt, pitkäikäisyys

Clean Architecture eristää liiketoimintalogiikan infrastruktuuritiedoista, jolloin sovelluksen ydinominaisuuksiin voidaan keskittyä. Tällöin ulkopuolisten tekijöiden, kuten tietokannan tai käyttöliittymän muutokset, eivät vaikuta sovelluksen perusrakenteeseen. Tämä takaa sovelluksen pitkäikäisyyden ja sopeutumiskyvyn.

Pese Clean Architecture:n edut

Riippumattomat ja eristetyt kerrokset: Jokaisella kerroksella on oma vastuunsa ja se toimii riippumatta muista kerroksista, mikä lisää modulaarisuutta.
Korkea testattavuus: Kukin kerros voidaan testata helposti itsenäisesti, mikä tuottaa luotettavampaa ohjelmistoa.
Helppo ylläpito ja päivitys: Koodin puhdas ja järjestelmällinen rakenne helpottaa ylläpitoa ja päivityksiä, mikä säästää aikaa ja kustannuksia.
Uudelleen käytettävyys: Kerrosten välinen erotus lisää mahdollisuuksia käyttää koodia eri projekteissa uudelleen.
Joustavuus ja skaalautuvuus: Arkkitehtuuri voi sopeutua erilaisiin teknologioihin ja vaatimuksiin, mikä lisää sovelluksen skaalautuvuutta.
Ymmärrettävyys: Koodin järjestelmällinen ja ymmärrettävä rakenne helpottaa uusien kehittäjien sopeutumista projektiin.

Tämä arkkitehtuurinen lähestymistapa helpottaa monimutkaisten järjestelmien hallintaa ja lisää kehitystiimien tehokkuutta. Clean Architecture on kriittisessä roolissa ohjelmointiprojektien onnistumisessa ja pitkän aikavälin kestävyydessä.

Clean Architecture:n tarjoamat edut ovat korvaamattomia nykyaikaisissa ohjelmistokehitysprosesseissa. Tämä arkkitehtuuri parantaa projektin laatua, vähentää kehityskustannuksia ja tukee pitkän aikavälin menestystä.

Vertailu Onion Architectureen

Clean Architecture ohjelmoinnissa ja Onion Architecture ovat kaksi merkittävää suunnitteluperiaatetta nykyaikaisessa ohjelmistokehityksessä. Molemmat pyrkivät siihen, että sovellukset ovat kestävämpiä, testattavampia ja helposti ylläpidettäviä. Kuitenkin niillä on joitain eroja tavoissa, joilla ne pyrkivät näihin tavoitteisiin ja niiden rakenteessa. Tässä osiossa vertaamme näitä kahta arkkitehtuuria ja tarkastelemme niiden välisiä keskeisiä eroja.

Clean Architecture ja Onion Architecture jakavat samankaltaisia filosofioita riippuvuuksien hallinnassa. Molemmat arkkitehtuurit kannustavat ulkoisten kerrosten riippuvaisuudelle sisäisistä kerroksista, samalla sisäkerrokset pysyvät riippumattomina ulkoisista kerroksista. Tämä mahdollistaa liiketoimintalogiikan eristämisen infrastruktuuritiedosta ja kehyksistä, mikä suojaa sovelluksen ydintä ulkoisilta muutoksilta.

Vertailu Onion Architectureen
Ominaisuus	Clean Architecture	Onion Architecture
Perusperiaate	Riippumattomuus ja testattavuus	Liiketoimintalogiikan keskiö
Kerrosten rakenne	Entities, Use Cases, Interface Adapters, Frameworks & Drivers	Domain, Application, Infrastructure, Presentation
Riippuvuuksien suunta	Sisäkerrokset ovat riippumattomia ulkoisista kerroksista	Ydinkerros on riippumaton ulkoisista kerroksista
Keskittymisalue	Liiketoimintalogiikan suojaaminen	Aluekeskeinen suunnittelu

Vertailun erityispiirteet

Riippuvuuksien hallinta: Sisäkerrosten riippumattomuus ulkoisista kerroksista.
Testattavuus: Jokaisen kerroksen itsenäinen testattavuus.
Kestävyys: Minimivastustus muutoksille.
Helppous ylläpidossa: Modulaarinen rakenne mahdollistaa helpon ylläpidon.
Joustavuus: Helppo mukautus eri teknologioihin ja kehykseen.

Rakenteelliset erot

Rakenteelliset erot Clean Architecture:n ja Onion Architecture:n välillä lepäävät kerrosten organisaatiossa ja vastuissa. Clean Architecture:ssa on selkeät ja tiukat kerrokset, kun taas Onion Architecture tarjoaa joustavamman rakenteen. Esimerkiksi Clean Architecture:ssa Interface Adapters -kerros mahdollistaa vuorovaikutuksen ulkomaailman kanssa, kun taas Onion Architecture:ssa tämäntyyppinen kerros voi olla yleisessä Infrastructure-kerroksessa.

Suorituskykyvaikutukset

Molempien arkkitehtuurien suorituskykyvaikutukset riippuvat sovelluksen erityistarpeista sekä arkkitehtuurin oikeasta toteutuksesta. Kerrosten välisten siirtymien ekokuorma voi olla hyväksyttävissä rajoissaan. Erityisesti liiketoimintalogiikan eristäminen ulkoisista muutoksista helpottaa suorituskyvyn optimointia. Lisäksi molemmat arkkitehtuurit mahdollistavat välimuistit sekä muut suorituskyvyn parantavat tekniikat. Oikealla suunnittelulla ja toteutuksella Clean Architecture ja Onion Architecture voidaan käyttää korkealaatuisten ja skaalautuvien sovellusten kehittämiseen.

Clean Architecture:n kerrokset ja roolit

Clean Architecture ohjelmoinnissa pyrkii jakamaan ohjelmointijärjestelmät itsenäisiin, testattaviin ja kestäviin osiin. Tämä arkkitehtuuri perustuu kerroksiin ja näiden kerrosten vastuisiin. Jokaisella kerroksella on tietyt vastuulliset tehtävät, ja se kommunikoi muiden kerrosten kanssa ainoastaan määriteltyjen rajapintojen kautta. Tämä lähestymistapa vähentää järjestelmän riippuvuuksia ja minimoi muutosten vaikutuksen.

Clean Architecture:ssa on yleensä neljä pääkerrosta: Entity (Yksiköt), Use Cases (Käyttötapaukset), Interface Adapters (Rajapinta-adapterit) ja Frameworks & Drivers (Kehykset ja ohjaimet). Nämä kerrokset seuraavat sisäpuolelta ulospäin suuntautuvaa riippuvuutta; eli sisäisimmät kerrokset (Entity ja Use Cases) eivät ole riippuvaisia mistään ulkoisista kerroksista. Tämä varmistaa, että liiketoimintalogiikka pysyy täysin itsenäisenä eikä altistu ulkopuolisten muutosten vaikutuksille.

Clean Architecture:n kerrokset ja roolit
Kerroksen nimi	Vastuut	Esimerkit
Entity (Yksiköt)	Käsittelee keskeisiä liiketoimintasääntöjä ja dataa.	Asiakas, Tuote, Tilaus jne.
Use Cases (Käyttötapaukset)	Määrittelee sovelluksen toiminnallisuuden; näyttää, miten käyttäjät käyttävät järjestelmää.	Uuden asiakkaan rekisteröinti, tilauksen luominen, tuotteen etsiminen.
Interface Adapters (Rajapinta-adapterit)	Muuttaa Use Cases-kurssin tiedot muodossa, joka on sopiva ulkomaailmalle ja päinvastoin.	Ohjaimet, Esittäjät, Portit.
Frameworks & Drivers (Kehykset ja ohjaimet)	Mahdollistaa vuorovaikutuksen ulkomaailman kanssa; tietokanta, käyttöliittymä, laiteohjaimet jne.	Tietokantajärjestelmät (MySQL, PostgreSQL), UI-kehykset (React, Angular).

Jokaisella kerroksella on oma roolinsa, ja näiden roolien selkeä määrittely helpottaa järjestelmän ymmärtämistä ja ylläpitämistä. Esimerkiksi Use Cases -kerros määrittelee, mitä sovellus tekee, kun taas Interface Adapters -kerros määrittelee, kuinka tämä toiminta esitetään. Tämä erottaminen mahdollistaa erilaisten teknologioiden tai rajapintojen vaihtamisen helposti.

Kerrosten roolit

Liiketoimintalogiikan suojaaminen: Sisäisimmät kerrokset sisältävät sovelluksen keskeiset liiketoimintatiedot, ja ne ovat riippumattomia ulkoisista kerroksista.
Riippuvuuksien hallinta: Kerrosten välinen riippuvuus hallitaan huolellisesti, jolloin muutokset eivät vaikuta muihin kerroksiin.
Testattavuuden lisääminen: Jokainen kerros voidaan testata itsenäisesti, mikä parantaa ohjelmiston laatua.
Joustavuuden tarjoaminen: Eri teknologiat tai rajapinnat voidaan helposti integroida tai vaihtaa.
Kestävyyden kasvattaminen: Rakenne tekee koodista järjestelmällisempää ja ymmärrettävämpää, mikä vähentää pitkän aikavälin ylläpitokustannuksia.

Tämä kerroksellinen rakenne muodostaa perustan Clean Architecture -malleille. Ymmärtäminen ja oikea toteuttaminen kunkin kerroksen vastuista auttaa kehittämään kestävämpiä, testattavampia ja joustavampia ohjelmistojärjestelmiä.

Clean käyttö parhaat käytännöt

Clean Architecture ohjelmoinnissa vaatii käytännön ja kurinalaisen lähestymistavan, eikä pelkästään teoreettista ymmärrystä. Kun omaksumme tämän arkkitehtuurin periaatteet, on tärkeää kiinnittää huomiota tiettyihin parhaisiin käytäntöihin koodin luettavuuden, testattavuuden ja kestävyyden lisäämiseksi. Alla on joitain keskeisiä strategioita, jotka auttavat sinua soveltamaan Clean -arkkitehtuuria projekteissasi menestyksellisesti.

Riippuvuuksien erottaminen tietokannasta, käyttöliittymästä ja ulkoisista palveluista on yksi Clean -arkkitehtuurin perusperiaatteista. Tämä erottaminen helpottaa liiketoimintalogiikan testaamista ja muokkaamista riippumatta ulkoisista asioista. Käytä rajapintoja (interfaces) riippuvuuksien abstrahoimiseen ja työnnätä konkreettiset toteutukset ulkoisiin kerroksiin; näin periaatteita toteutetaan tehokkaasti. Esimerkiksi, kun tarvitset tietokantaoperaatiota, älä käytä suoraan tietokantaluokkaa, vaan määrittele rajapinta ja käytä luokkaa, joka toteuttaa tämän rajapinnan.

Keskeiset sovellussuositukset

Noudata Yhden Vastuun Periaatetta (SRP): Jokaisella luokalla ja moduulilla tulisi olla vain yksi toiminto, ja sen tulisi olla vastuussa vain sen toteuttamisesta.
Ota käyttöön Riippuvuuksien Käännön Periaate (DIP): Korkean tason moduulit eivät saisi olla suoraan riippuvaisia alemmista moduuleista. Molemmat tulisi perustua abstrahditiin (rajapintoihin).
Käytä rajapintoja järkevästi: Rajapinnat ovat vahvoja työkaluja kerrosten välisen viestinnän ja riippuvuuksien vähentämiseen. Älä luo rajapintaa jokaiselle luokalle, vaan määrittele vain ne, jotka ovat välttämättömiä liiketoimintasi abstrahoimiseksi ulkoisista tekijöistä.
Hyväksy Testivetoinen Kehitys (TDD): Kirjoita testit ennen koodauksen aloittamista. Tämä auttaa sinua varmistamaan koodisi toimivuuden ja ohjaamaan suunnittelupäätöksiäsi.
Ole aluekeskeinen: Heijasta liiketoimintavaatimuksesi ja alueosaamisesi koodissasi. Käyttämällä aluekeskeisiä suunnitteluperiaatteita (DDD) voit tehdä liiketoimintalogiikastasi ymmärrettäviä ja kestäviä.

Testattavuus on yksi Clean -arkkitehtuurin tärkeimmistä eduista. Jokaisen kerroksen ja moduulin itsenäinen testattavuus parantaa sovelluksen yleistä laatua ja auttaa löytämään virheitä aikaisessa vaiheessa. Käytä yksikkötestejä (unit tests), integraatiotestejä ja käyttäytymisvetoista kehitystä (BDD) kattavasti testataksesi sovellus.

Clean käyttö parhaat käytännöt
Parhaat käytännöt	Kuvaus	Edut
Riippuvuuksien injektointi	Luokka saa riippuvuutensa ulkopuolelta.	Joustavampi, testattavampi ja uudelleenkäytettävä koodi.
Rajapintojen käyttö	Kerrosten välinen viestintä on järjestetty rajapintojen kautta.	Vähentää riippuvuuksia, lisää muutosvastarintaa.
Testiautomaation käyttö	Automatisoi testiprosessit.	Nopea palaute, jatkuva integraatio ja luotettava jakelu.
SOLID-periaatteet	Suunnitelma SOLID-periaatteita noudattaen.	Helpommin ymmärrettävä, kestävämpi ja laajennettavampi koodi.

Clean -arkkitehtuuria soveltaessasi on tärkeää ottaa huomioon projektisi erityistarpeet ja rajoitukset. Jokainen projekti on ainutlaatuinen, eikä jokainen arkkitehtuurinen lähestymistapa sovi jokaiseen tilanteeseen. Ole joustava, sopeudu ja ole aina oppimisen ja kasvuun avoin. Ajan myötä tulet löytämään parhaat tavat soveltaa Clean -arkkitehtuurin periaatteita omissa projekteissasi.

Clean ja Onion Architecture:n yhteiset ominaisuudet

Clean Architecture ja Onion Architecture:n yhteiset ominaisuudet

Clean Architecture ja Onion Architecture ovat merkittävässä asemassa nykyaikaisessa ohjelmistokehitysprosesseissa, ja molemmat pyrkivät luomaan kestäviä, testattavia ja helposti ylläpidettäviä sovelluksia. Vaikka ne ovat eri arkkitehtuurisia lähestymistapoja, niillä on monia yhteisiä piirteitä perusperiaatteissa ja tavoitteissa. Nämä yhteiset piirteet tarjoavat kehittäjille ohjausta molempien arkkitehtuurien ymmärtämisessä ja soveltamisessa. Molemmat rakenteet käyttävät kerroksellista rakennetta hallitakseen järjestelmien monimutkaisuutta ja vähentääkseen riippuvuuksia. Nämä kerrokset erottavat liiketoimintalogiikan ja sovellusalueen sovellusinfrastruktuurista, mikä luo Clean suunnittelun.

Pohjimmiltaan sekä Clean Architecture että Onion architecture puolustavat sitä, että liiketoimintalogiikka ja sovellusalue tulisi sijoittaa sovelluksen ytimeen. Tämä tarkoittaa, että infrastruktuuritiedot, kuten tietokannat, käyttöliittymät ja ulkoiset palvelut, ovat irti ytimestä. Tämän ansiosta infrastruktuuriteknologian muutokset eivät vaikuta sovelluksen ytimeen, mikä tekee sovelluksesta joustavamman ja sopeutettavamman. Tällainen lähestymistapa parantaa testattavuutta, koska liiketoimintalogiikka ja sovellusalue voidaan testata eristyksissä infrastruktuurisidonnaisuuksista.

Yhteiset periaatteet

Riippuvuuksien kääntäminen: Molemmat arkkitehtuurit kannattavat, että korkean tason moduulien ei pitäisi olla riippuvaisia matalan tason moduuleista.
Liiketoimintalogiikan priorisointi: Liiketoimintalogiikka on sijoitettava sovelluksen ytimeen, ja kaikki kerrokset tukevat tätä ydintä.
Testattavuus: Kerroksellinen rakenne helpottaa eristyneen testauksen.
Helppo ylläpito: Modulaariset ja riippumattomat rakenteet parantavat koodin luettavuutta ja ylläpitämistä.
Joustavuus ja sopeutettavuus: Infrastruktuurisi tarkastelu ytimestä eristyksessä tekee sovelluksen helpommin mukautettavaksi eri ympäristöihin ja teknologioihin.

Molemmat arkkitehtuurit varmistavat, että sovelluksen eri osien vastuut ovat selkeästi määriteltyjä, mikä tekee koodista ymmärrettävämmän ja järjestelmällisemmän. Tämä helpottaa uusien kehittäjien liittymistä projekteihin ja uusien muutosten tekemistä olemassa olevaan koodiin. Lisäksi nämä arkkitehtuurit lisäävät sovellusten skaalautuvuutta, sillä jokainen kerros voidaan eristää ja optimoida itsenäisesti.

Sekä Clean Architecture että Onion Architecture edistävät parempaa yhteistyötä ja viestintää ohjelmistokehityksen aikana. Selkeästi määritellyt kerrokset ja vastuut helpottavat eri kehitystiimien rinnakkaista työskentelyä saman projektin parissa. Tämä lyhentää projektin toimitusaikoja ja parantaa tuotteen laatua. Nämä yhteiset ominaisuudet auttavat kehittäjiä luomaan luotettavampia, joustavampia ja kestävämpiä Clean -rakenteisia sovelluksia.

Joyce M. Ononen näkemys: Clean Architecture

Joyce M. Onone on tunnettu nimi ohjelmistokehitysmaailmassa, erityisesti Clean -arkkitehtuurin syvällisten tutkimusten ansiosta. Ononen näkökulma keskittyy ohjelmistoprojektien kestävyyteen, testattavuuteen ja helppoon ylläpidettävyyteen. Hänen mukaansa Clean Architecture ei ole vain suunnittelumalli, vaan myös ajattelutapa ja kurinalaisuus. Tämä kurinalaisuus auttaa ohjelmistokehittäjiä hallitsemaan monimutkaisuutta ja rakentamaan pitkäaikaisen arvon tuottavia järjestelmiä.

Yksi Ononen korostamista tärkeistä seikoista on, että Clean Architecturen riippuvuuksien asianmukainen hallinta on suoraan yhteydessä siihen. Hän toteaa, että kerrosten välisten riippuvuuksien suunta määrittää järjestelmän yleisen joustavuuden ja sopeutumiskyvyn. Sisäkerrosten ei tulisi olla riippuvaisia ulkoisista kerroksista, jotta liiketoimintalogiikka pysyisi eristyksissä infrastruktuurista. Tämä mahdollistaa ohjelmiston toimimisen eri ympäristöissä ja helpottaa vaatimusten muutoksiin sopeutumista.

Joyce M. Ononen näkemys: Clean Architecture
Clean Architecture -periaate	Joyce M. Ononen kommentti	Käytännön sovellukset
Riippuvuuksien käännös	Riippuvuudet tulisi rakentaa abstrahdoista, ja konkreettiset tiedot tulisi olla alistettuina.	Rajapintoja käyttämällä voit vähentää riippuvuuksia kerrosten välillä.
Yhden vastuun periaate	Jokaisella moduulilla tai luokalla tulisi olla vain yksi toiminnallinen vastuu.	Suuret luokat voidaan jakaa pienempiin ja tarkemmin kohdistettuihin luokkiin.
Rajapinnan erottamisen periaate	Asiakkaat eivät saisi olla riippuvaisia rajapintoja, joita he eivät käytä.	Erityisrajoitteiden avulla asiakkaat voivat käyttää vain tarvittavia toimintojaan.
Avoimuuden/sulkemisen periaate	Luokkien ja moduulien tulisi olla laajennettavia, mutta ei muokattavia.	Käytä perintöä tai kokoonpanoa lisätäksesi toimintoja ilman nykyisten toimintojen muuttamista.

Onone korostaa, että Clean Architecture:n tarjoamat hyödyt eivät ole vain teknisiä, vaan ne vaikuttavat myös liiketoimintaprosesseihin. Hyvin suunniteltu Clean Architecture rakenne mahdollistaa kehitystiimien nopeamman ja tehokkaamman toiminnan. Kun koodi on luettavissa ja ymmärrettävää, uusien kehittäjien on helpompi liittyä projekteihin ja virheiden korjaaminen on nopeampaa. Tämä edistää projektien saamista valmiiksi aikarajoissa ja budjetin puitteissa.