Yazılım Mimarisi Nedir ?
Yazılım Mimarisi (Software Architecture) bir sistemin paçalarını ve aralarındaki ilişkiyi gösterir. Mevcut bir yazılımın mimarisini değiştirmek zor bir iştir.
Mimarisel Nasıl Ortaya Çıkar
Mimari bir anda ortaya çıkmaz. Genellikle artırımsal yinelemelerle hayat bulur. Çünkü insanlar bir seferde her şeyi göremezler. Açıklaması şöyle.
Bazı yazılım mimarileri tekrarlana tekrarlana, artık bir referans model haline gelebilir. Açıklaması şöyle
Burada ilginç bir konu var. Açıklaması şöyle. Çeşitli yazılım mimarilerine göre ekibi de düzenlemek gerekebilir. Çünkü Conway yasasına göre, yazılım ekiplerin iletişim yapısına göre şekillenecektir.
Bazı Mimarisel Örüntüler
Yazılım Mimarisi (Software Architecture) bir sistemin paçalarını ve aralarındaki ilişkiyi gösterir. Mevcut bir yazılımın mimarisini değiştirmek zor bir iştir.
Mimarisel Nasıl Ortaya Çıkar
Mimari bir anda ortaya çıkmaz. Genellikle artırımsal yinelemelerle hayat bulur. Çünkü insanlar bir seferde her şeyi göremezler. Açıklaması şöyle.
We call this emergent design.Mimarisel Örüntüler - Architectural Pattern
There are a number of techniques that can be used to encourage emergent design. Agile is a common methodology of emergent design.
Bazı yazılım mimarileri tekrarlana tekrarlana, artık bir referans model haline gelebilir. Açıklaması şöyle
Architectural patterns are ways of capturing proven good design structures, so that they can be reused. Software architects have been looking for ways to capture and reuse the architectural knowledge that have proven successful in the past.Yazılım Mimarisi ve Ekip Yapısı
More specifically, an architectural pattern is a package of design decisions that is found repeatedly in practice, has well defined properties that can be reused and describes a class of architectures.
Developing an architecture can be seen as a process of selecting, tailoring, and combining patterns. The software architect must decide how to instantiate a pattern, how to make it fit with the specific context and the constraints of the problem.
Burada ilginç bir konu var. Açıklaması şöyle. Çeşitli yazılım mimarilerine göre ekibi de düzenlemek gerekebilir. Çünkü Conway yasasına göre, yazılım ekiplerin iletişim yapısına göre şekillenecektir.
Several studies have confirmed the core message of Conway’s Law that “Any organization that designs a system ... will produce a design whose structure is a copy of the organization's communication structure.” There are many subtleties to this in practice, but it boils down to this: If the intercommunication between teams does not reflect the actual or intended communication between software components, the software will be difficult to build and operate.
You can use “Reverse Conway”—changing the team structure to match the required system architecture—together with techniques such as domain-driven design (DDD) and code forensics, to reshape team responsibilities to align with the software architecture you need to produce in order to clarify boundaries and improve the development and operation of your systems.
Örnek
Örneğin eğitmen + kırmızı öğrenciler + mavi öğrenciler ilişkisi olan 3 tane ekip olsun. Her öğrenci grubu sadece kendi aralarında iletişim kurabilsinler ve eğitmen ile iletişim kurabilsinler. Bu durumda - - eğitmene ait ekranlar kırmızı + mavi tüm nesneleri gösterebilecek şekilde olacaktır. Eğitmen öğrencilerden gelen isteklere cevap veren ekranlara da sahip olacaktır
- öğrenci grupları sadece kendi renklerine ait nesneleri yöneteceklerdir. Eğer aralarında hiyerarşi varsa yine aynı şekilde nesneler belli rollere de atanabilir.
Bu örnekte bariz bir şekilde yazılım da aynı şekilde geliştirilecektir.
Örnek
Mesela micro service mimarisine uygun yazılım geliştirmek isteyelim. O zaman Reverse Conway yasası uyarınca, ekipleri daha küçük ve bağımsız olacak şekilde düzenlemek gerekir. Açıklaması şöyle
This is one reason why organizations like Amazon and Netflix work in small, independent teams. It enables API-first design and development. And is represented as the well-known microservices deathstar.
Bazı Mimariler
-Client/Server
-Peer to Peer
-Event Driven Architecture (EDA)
-Pipe and Filter Architecture
-Layered Architecture veya N-Layered Architecture
-Onion Architecture
-Hexagonal Architecture
-DCI Architecture
-Microkernel Architecture
-Microservices Architecture yazısına taşıdım.
- Space-Based Architecture yazısına taşıdım.
-Client/Server
-Peer to Peer
-Event Driven Architecture (EDA)
-Pipe and Filter Architecture
-Layered Architecture veya N-Layered Architecture
-Onion Architecture
-Hexagonal Architecture
-DCI Architecture
-Microkernel Architecture
-Microservices Architecture yazısına taşıdım.
-Service Oriented Architecture - SOA yazısına taşıdım.
-Microservices Architecture yazısına taşıdım.- Space-Based Architecture yazısına taşıdım.
Yazılım ve Veri
Veri (data) , yazılım yeniden inşa edilse bile halen yaşamaya devam edecek tek şey olacaktır. Bu yüzden, veri modelini dikkat etmek gerekir.
Yazılım Kalite Etmenleri (Software Quality Attributes)
Yazılım Mimarı, kalite etmenlerinin seçilmesine dikkat eder. Yazılım Kalite Etmenleri yazısına taşıdım
Veri (data) , yazılım yeniden inşa edilse bile halen yaşamaya devam edecek tek şey olacaktır. Bu yüzden, veri modelini dikkat etmek gerekir.
Yazılım Kalite Etmenleri (Software Quality Attributes)
Yazılım Mimarı, kalite etmenlerinin seçilmesine dikkat eder. Yazılım Kalite Etmenleri yazısına taşıdım