{"id":2847,"date":"2019-10-26T23:04:58","date_gmt":"2019-10-26T20:04:58","guid":{"rendered":"https:\/\/gokhan-gokalp.com\/?p=2847"},"modified":"2019-10-27T12:20:10","modified_gmt":"2019-10-27T09:20:10","slug":"getting-started-with-clean-architecture-using-asp-net-core-01","status":"publish","type":"post","link":"https:\/\/gokhan-gokalp.com\/tr\/getting-started-with-clean-architecture-using-asp-net-core-01\/","title":{"rendered":"Getting Started with Clean Architecture using ASP.NET Core – 01"},"content":{"rendered":"

Biliyoruz ki maintenance<\/strong> i\u015flemi, uygulaman\u0131n kendisini yazmaktan her zaman daha maliyetli bir operasyondur. Her ne yaparsak yapal\u0131m, de\u011fi\u015fmeyen tek ger\u00e7ek maintenance maliyetidir, de\u011fil mi?<\/p>\n

\"\"<\/a><\/p>\n

Bu maliyeti etkileyen en \u00f6nemli etkenlerden birisi de, uygulaman\u0131n architecture’\u0131n\u0131n se\u00e7imidir. Edindi\u011fim ge\u00e7mi\u015f tecr\u00fcbelerim do\u011frultusunda iki farkl\u0131 makale serisi olarak, “iyi bir architecture design edebilmek i\u00e7in nelere dikkat etmeliyiz<\/em>” ve “clean architecture nedir<\/em>” konular\u0131na de\u011finmeye \u00e7al\u0131\u015faca\u011f\u0131m.<\/p>\n

Peki,<\/p>\n

\u2015 Robert C. Martin<\/em>, iyi bir architecture’\u0131 Clean Architecture<\/strong> kitab\u0131nda, a\u015fa\u011f\u0131daki gibi tan\u0131mlamaktad\u0131r;<\/p>\n

Good architecture makes the system easy to understand<\/strong>, easy to develop<\/strong>, easy to maintain<\/strong>, and easy to deploy<\/strong>. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.<\/em><\/p><\/blockquote>\n

Zaten bir architecture design ederken temel gayelerimiz de bunlard\u0131r, de\u011fil mi? San\u0131r\u0131m clean architecture’\u0131n \u00f6nemi, bu gayeler ile ba\u015fl\u0131yor. Bana g\u00f6re iyi bir architecture design edebilmek i\u00e7in dikkat etmemiz gereken ba\u015fl\u0131ca iki temel kavram bulunmaktad\u0131r. “Coupling<\/em>” ve “Separation of Concerns<\/em>” kavramlar\u0131.<\/p>\n

Haydi hat\u0131rlayal\u0131m…<\/p>\n

Coupling<\/h2>\n

K\u0131saca coupling’in tan\u0131m\u0131n\u0131 hat\u0131rlayal\u0131m. Coupling i\u00e7in, mod\u00fcller aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131n derecesinin bir \u00f6l\u00e7\u00fct\u00fcd\u00fcr diyebiliriz.<\/p>\n

Bildi\u011fimiz gibi genelde bunu ise, loosely coupling<\/strong> ve tightly coupling<\/strong> olarak ele al\u0131r\u0131z. \u0130yi bir architecture’a sahip uygulama geli\u015ftirmek istiyorsak, uygulamam\u0131z\u0131\/mod\u00fcllerimizi loosely coupled olarak geli\u015ftirmemiz gerekmektedir.<\/p>\n

\u00d6zetle, mod\u00fcllerimiz birbirlerine “s\u0131k\u0131 s\u0131k\u0131ya” ba\u011fl\u0131 olmamal\u0131d\u0131rlar. “Geni\u015fletilebilir” ve kolayl\u0131kla “de\u011fi\u015ftirilebilir” olmal\u0131d\u0131rlar.<\/p>\n

Separation of Concerns (SoC)<\/h2>\n

Bir di\u011fer \u00f6nemli kavram ise separation of concerns(SoC<\/a>)<\/em>. Buradaki temel hedef, design veya kod taraf\u0131ndaki farkl\u0131 concern’lerin ayn\u0131 yerde handle edilmeye \u00e7al\u0131\u015f\u0131lmas\u0131n\u0131 engellemektir. Bu konu asl\u0131nda, SOLID<\/em> prensiplerinden birisi olan “Single Responsibility<\/em>” prensibi ile olduk\u00e7a ilgilidir.<\/p>\n

\u00d6rne\u011fin, business logic i\u00e7erisinde data access i\u015flemlerini de handle etmek veya UI<\/em> representation i\u015flemlerini de ger\u00e7ekle\u015ftirmek gibi d\u00fc\u015f\u00fcnebiliriz. Bir s\u00fcre sonra ortaya binlerce sat\u0131rl\u0131k god class’lar<\/strong> ve spagetti kodlar<\/strong> \u00e7\u0131kmaya ba\u015fl\u0131yor.<\/p>\n

\"\"<\/a><\/p>\n

San\u0131r\u0131m spagetti sadece bir besin \u00f6\u011fesi iken g\u00fczel.<\/em><\/p><\/blockquote>\n

Bu tarz i\u015flemler, SoC<\/em>‘\u00fc ihlal etmektedir. Hat\u0131rlayal\u0131m, iyi bir architecture, kolay “maintain” edilebilmeli, daha az “coupled” ve kolayca “extend” edilebiliyor olmal\u0131d\u0131r.<\/p>\n

SoC<\/em>, \u00f6zellikle layered bir architecture design edebilmek i\u00e7in olduk\u00e7a \u00f6nemli bir kavramd\u0131r. Mod\u00fcllerimizin olabildi\u011fince loosely coupled ve high cohesion<\/strong> olmas\u0131na dikkat etmeliyiz. \u0130\u00e7lerindeki sorumluluk ili\u015fkisi olabildi\u011fince y\u00fcksek<\/strong> ve alakal\u0131<\/strong> olmal\u0131d\u0131r, farkl\u0131 concern’ler ile ilgilenmemelidirler.<\/p>\n

\"\"<\/a><\/p>\n

Layered Architecture<\/h2>\n

Layered architecture, biz yaz\u0131l\u0131mc\u0131lar\u0131n hayat\u0131nda b\u00fcy\u00fck bir yere sahiptir san\u0131r\u0131m. En az\u0131ndan benim i\u00e7in \u00f6yle.<\/p>\n

Layered architecture arkas\u0131ndaki ana prensip’lerden birisi, SoC<\/em>‘d\u00fcr. Hedef ise database, domain veya UI<\/em> code’unun birbirlerine kar\u0131\u015fmas\u0131n\u0131 engellemek ve sorumluluklar\u0131n\u0131 ay\u0131rmakt\u0131r.<\/p>\n

\"\"<\/a><\/p>\n

Layered architecture genelde, yukar\u0131daki gibi bir form’da kar\u015f\u0131m\u0131za gelmektedir. Buradaki dependency ak\u0131\u015f\u0131 ise, presentation’dan, data access layer’a do\u011frudur. Asl\u0131nda bakarsan\u0131z, her ne kadar SoC<\/em>‘\u00fc ve loosely coupling’i sa\u011flamaya \u00e7al\u0131\u015f\u0131yor olsak da, layer’lar aras\u0131nda bir hiyerar\u015fi, dependency s\u00f6z konusudur.<\/p>\n

Clean architecture’\u0131n arkas\u0131ndaki ana prensip’lerden birisi ise, Dependency Inversion<\/em> prensibidir. Bu prensip ile mimari i\u00e7erisindeki mod\u00fcllerimizi birbirinden ve farkl\u0131 teknolojilerden daha decoupled<\/strong> bir hale getirebilmek m\u00fcmk\u00fcnd\u00fcr.<\/p>\n

\"\"<\/a><\/p>\n

G\u00f6rsele bir de bu \u015fekilde bakal\u0131m.<\/p>\n

Uncle Bob<\/em>‘un “Clean Architecture” olarak adland\u0131rd\u0131\u011f\u0131 concept veya Alistair Cockburn<\/em>‘un “Hexagonal Architecture” olarak adland\u0131rd\u0131\u011f\u0131 design yukar\u0131daki gibidir. Dependency inversion uygulanm\u0131\u015f, domain-centric bir design.<\/p>\n

Yukar\u0131dan a\u015fa\u011f\u0131ya do\u011fru hiyerar\u015fik bir ak\u0131\u015f yerine, application domain’i, yani business logic ve domain modellerin i\u00e7erisinde bar\u0131nd\u0131\u011f\u0131 b\u00f6l\u00fcm\u00fc core olarak ortada konumland\u0131rmaktad\u0131r. Ayr\u0131ca di\u011fer t\u00fcm mod\u00fcllerin ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 da tersine \u00e7evirmektedir. Dependency ak\u0131\u015f\u0131 ise her zaman ortaya, yani core k\u0131sma do\u011fru ger\u00e7ekle\u015fmektedir. Plug-in yap\u0131s\u0131 gibi d\u00fc\u015f\u00fcnebiliriz. Tak, \u00e7\u0131kart.<\/p>\n

Bu yakla\u015f\u0131m ise bize, herhangi bir par\u00e7ay\u0131 istedi\u011fimiz gibi kolayl\u0131kla extend edebilme, test edebilme ve de\u011fi\u015ftirebilme yeteneklerini kazand\u0131rmaktad\u0131r.<\/p>\n

Neden Clean Architecture?<\/h2>\n
    \n
  1. De\u011fi\u015ftirilmesi zor:\u00a0<\/strong>Business ihtiya\u00e7lar\u0131 genelde bitmez. Her zaman uygulamam\u0131za yeni \u00f6zellikler eklemeye ihtiya\u00e7 duyar\u0131z. E\u011fer d\u00fczg\u00fcn bir architecture in\u015fa etmez isek, bu de\u011fi\u015fiklikleri implemente etmemiz hem zorla\u015facak, hem de projeyi daha karma\u015f\u0131k bir hale getirecektir. Ayr\u0131ca projeyi maintain edilebilmesi zor ve k\u0131r\u0131lganl\u0131\u011f\u0131 fazla bir yap\u0131ya do\u011fru itmi\u015f olabiliriz.<\/li>\n
  2. Test etmesi zor:<\/strong> \u0130yi in\u015fa edilmemi\u015f bir architecture’da, test edilebilirlik bi o kadar zordur. Ya business logic her tarafa duplicate bir \u015fekilde yay\u0131lm\u0131\u015ft\u0131r, ya UI<\/em> ile i\u00e7 i\u00e7e ge\u00e7mi\u015ftir, yada component’ler birbirlerine s\u0131k\u0131 s\u0131k\u0131ya ba\u011fl\u0131d\u0131r. K\u0131r\u0131lganl\u0131k \u00e7ok fazla olunca, geni\u015fletilebilirlik de zorla\u015f\u0131yor ve yapt\u0131\u011f\u0131m\u0131z bir de\u011fi\u015fikli\u011fin nereleri etkiledi\u011fini g\u00f6rebilme ve test edebilme i\u015flemlerimiz de zorla\u015f\u0131yor.<\/li>\n
  3. Database’lerden, framework’lerden ve external library’lerden ba\u011f\u0131ms\u0131zl\u0131k<\/strong>: Bir di\u011fer \u00f6nemli konu ise, core application domain layer’\u0131n database’lerden, framework’lerden veya external librirary’lerden olabildi\u011fince soyut tutabilmektir. Buda bize, istedi\u011fimiz bir zaman farkl\u0131 bir y\u00f6ntemle, farkl\u0131 bir framework’le ilerleyebilme, yani flexibility yetene\u011fini kazand\u0131racakt\u0131r.<\/li>\n<\/ol>\n

    \"\"<\/a><\/p>\n

    Yukar\u0131daki makas’\u0131, bir b\u0131\u00e7ak ile yer de\u011fi\u015ftirmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z\u0131 d\u00fc\u015f\u00fcnebiliyor musunuz?<\/em><\/p><\/blockquote>\n

    \u0130yi Bir Architecture’a Sahip Uygulama Nedir?<\/h2>\n

    Genelde iyi bir architecture’a sahip uygulamadan, a\u015fa\u011f\u0131daki concern’leri cover edebiliyor olmas\u0131n\u0131 bekleriz.<\/p>\n

      \n
    1. Testability:<\/strong> Geli\u015ftirdi\u011fimiz kod\/component par\u00e7alar\u0131n\u0131n, bireysel olarak her birinin kolayca test edilebilir olmas\u0131 gerekmektedir.<\/li>\n
    2. Maintainability:<\/strong> Bildi\u011fimiz gibi her \u015feyden \u00f6nce uygulaman\u0131n s\u00fcrd\u00fcr\u00fclebilir olmas\u0131 b\u00fcy\u00fck bir \u00f6nem ta\u015f\u0131maktad\u0131r. Kolay bir \u015fekilde maintenance i\u015flemlerini ger\u00e7ekle\u015ftirebiliyor olmal\u0131y\u0131z.<\/li>\n
    3. Extendability:<\/strong> Mevcut mod\u00fclleri, component’leri y\u0131kmadan\/de\u011fi\u015ftirmeden, onlar\u0131 kolayl\u0131kla geni\u015fletebiliyor olmal\u0131y\u0131z.<\/li>\n
    4. Reusability:<\/strong> Geli\u015ftirmi\u015f oldu\u011fumuz mod\u00fcller, tekrar kullan\u0131labilir olmal\u0131d\u0131r.<\/li>\n
    5. Readability:<\/strong> Ekibe yeni bir developer kat\u0131ld\u0131\u011f\u0131nda, kolayca projeye adapte olabilmesi de, di\u011fer maddeler kadar b\u00fcy\u00fck bir \u00f6nem ta\u015f\u0131maktad\u0131r.<\/li>\n<\/ol>\n

      \"\"<\/a><\/p>\n

      Yukar\u0131daki g\u00f6rsele tekrar bakt\u0131\u011f\u0131m\u0131zda di\u011fer aletleri etkilemeden makas’\u0131, b\u0131\u00e7ak ile\u00a0 de\u011fi\u015ftirebilmenin ne kadar da daha kolay olaca\u011f\u0131n\u0131 g\u00f6rebiliriz.<\/em><\/p><\/blockquote>\n

      Clean Architecture Konsepti<\/h2>\n

      Peki, \u015fimdi clean architecture konsept’inin detaylar\u0131na bir bakal\u0131m.<\/p>\n

      \u00d6ncelikle a\u015fa\u011f\u0131da g\u00f6r\u00fcyor oldu\u011fumuz Hexagonal<\/em> architecture, clean architecture konsept’inin uygulanm\u0131\u015f bir \u00f6rne\u011fidir.<\/p>\n

      \"\"<\/a><\/p>\n

      “Application Domain” layer, en i\u00e7 core layer’d\u0131r. Architecture’\u0131n kalbi. Herhangi bir dependency’si bulunmamaktad\u0131r. Database, UI<\/em> vb. framework’lerden isolated bir \u015fekilde ortada konumlanmaktad\u0131r. \u0130\u00e7erisinde ba\u015fl\u0131ca domain entity’lerini<\/strong>, use-case’leri<\/strong> ve external interface’leri<\/strong> bar\u0131nd\u0131rmaktad\u0131r.<\/p>\n

      Etraf\u0131nda ise, “input” ve “output” port’lar\u0131 bulunmaktad\u0131r. Etraf\u0131ndaki implementasyon’lar ise, “adapter” olarak adland\u0131r\u0131lmaktad\u0131r. Bu adapt\u00f6r’ler ise, port’lar\u0131 implemente etmektedir.<\/p>\n

      Entities<\/h3>\n