ACID - Read Committed Seviyesi Nedir ?

Giriş

Şeklen şöyle. İkinci satırda Repeatable Read görülebilir.

SQL Server için şeklen şöyle

PostgreSQL için açıklama şöyle. Yani PostgreSQL'in desteklediği en düşük ve ilk seviye bu

In PostgreSQL, you can request any of the four standard transaction isolation levels, but internally only three distinct isolation levels are implemented, i.e. PostgreSQL's Read Uncommitted mode behaves like Read Committed. This is because it is the only sensible way to map the standard isolation levels to PostgreSQL's multiversion concurrency control architecture.

Designing Data Intensive Applications kitabındaki açıklama şöyle.

The most basic level of transaction isolation is read committed. It makes two guarantees:

1. When reading from the database, you will only see data that has been committed

(no dirty reads).

2. When writing to the database, you will only overwrite data that has been committed

(no dirty writes).

Yani

- Sadece Dirty Read ve Dirty Write problemini engeller. 

- Non Repeatable Read problemini engellemez. Aynı transaction içinde iki okuma farklı sonuç verebilir, çünkü başka transaction veriyi değiştirebilir.

- Lost Update problemini engellemez

- Phantom Read problemini engellemez. Benim dokunmadığım satırlar kilitlenmediği için bunlar değiştirilebilir veya yeni satır eklenebilir

- Phantom satır kapsamında Write skew problemini engellemez.

Non-Repetable Read

Örnek

Şeklen şöyle. Açıklaması şöyle

In the following diagram, the concurrent transactions see the real-time change the other made. Transaction 1 gets chris as the latest committed name even though Transaction 2 began after Transaction 1.

Burada Transaction 1 başlıyor ve 2 numaralı satırı okuyor, ancak 3 numaralı satıra dokunmuyor. Transaction 2 ise 3 numaralı satırı değiştirip commit'liyor. Transaciton 2, 3 numaralı satırı okursa değişmiş veriyi görüyor. Bu problemin ismi "Non-Repeatable Read" ve "Repeatable Read" isolation seviyesi bu problemi engeller.

Select İşlemi - Non Repeatable Read Problemi

Read Committed seviyesinde select cümlesinin başında konulan shared lock, cümle bitiminde transaction bitmemiş olsa bile kaldırılır. Açıklaması şöyle

T1 gets Read Lock, reads, and releases the Read lock asap once the read is done.

T2 can execute and update the row as it is unlocked now.

So When T1 tries to re-read the same row, it will get a different result.

Örnek

Şöyledir

T1 begins

T1 Reads A‘s Balance=Rs. 1000 [Read-1]

T2 begins

T2 Read A’s Balance= Rs. 1000 (Can read as Row= Read Locked)

(T1 reads and releases Read Lock ASAP, and the row is unlocked now)

T2 Update A’s Balance= Rs. 500 (Can Write as Write lock is free for this row)

T2 Commit. (Releases Write Lock, now row is free to Read/Write)

T1 Reads A‘s Balance=Rs. 500 [Read-2] [Different Result] [non-Repeatable]

Select İşlemi - Phantom Reads Problem

Örnek

Şöyledir

T1 begins

T1Queries select * from Tbl where X>100 → 3 rows

T2 begins

T2 Inserts 1 additional row with X=150.

T2 Commits.

T1 Queries select * from Tbl where X>100 → 4rows [Phantom Read].

ACID - Phantom Read Nedir ? (Eksik veya fazla satır)

Giriş

Şeklen şöyle

Açıklaması şöyle

A phantom read occurs when two identical queries are executed during a transaction and the row collection returned by the second query is different from the first

Phantom Read 2 şekilde ortaya çıkar

1. Belli bir koşula bakılarak satır eklenmesi/çıkarılması

1. Belli bir koşula bakmadan satır eklenmesi/çıkarılması

1. Belli bir koşula bakılarak satır eklenmesi/çıkarılması

Açıklaması şöyle. Burada SELECT ile bir koşula veya sayaç değerine bakılıyor. Daha sonra satır ekleniyor/çıkartılıyor

Having said that, a phantom read would always follow the same pattern

1. Run a SELECT query to get data that matches certain conditions.

2. Depending on the result of first the transaction either proceeds or aborts.

3. If the transaction proceeds ahead then you make some INSERT, UPDATE, DELETE call and commits the transaction.

Açıklaması şöyle

This is a very common problem and can happen in these sort of systems

1. Booking system (Two people book the same room)

2. User management system (Two people get the same username)

3. Customer service system (One agent gets assigned multiple calls at the same time)

Örnek

Bir örnek şöyle

The item count is 1 in the database.

1. User 1 fetches the count and gets 1 in return.

2. User 2 fetches the count and gets 1 in return.

3. User 1 sees count > 0, assumes the item is available and places the order, and decrements the count by 1.

4. User 2 sees count > 0, assumes the item is available and places the order, and decrements the count by 1.

5. User 1 order placed.

6. User 2 order placed.

Açıklaması şöyle

So both the user was actually able to book the item even though only 1 item was available. ... In simple words, multiple transactions read the same object to decide if a transaction should go through and then might update that or other objects.

2. Belli bir koşula bakmadan satır eklenmesi/çıkarılması

Açıklaması şöyle

This can happen if T1 queries some range of rows (say N rows), and meanwhile, T2 inserts an extra row matching the same query conditions of T1.

Then if T1 searches again, it will get an additional row(phantom read).

Kısaca aynı transaction içinde aynı sorguyu iki defa çalıştırıp, bir başka transaction'ının satır ekleyip silmesi yüzünden, eksik veya fazla satır sayısının alınması anlamına geliyor. 

Burada dikkat edilmesi gereken şey her iki sorguda da mevcut olan satırların aynı değerlere sahip olmasının garanti edilmesi. Sadece aradaki satırlar eklenip çıkarılabiliyor. Aynı değere sahip olmasının garanti edilmesi Read Committed Seviyesinde Select başlığındaki SCN numarası ile alakalı.

- Eksik veya fazla satırın olması select sum(x) from table; gibi sql cümlelerinde probleme sebep olabilir.

- Eğer primary key kullanarak tek bir satır çekiyorsak phantom read olma olasılığı ortandan kalkar.

Örnek

Bir örnek burada

Çözüm

1. "Select For Update" Kullanılabilir. "Select For Update" dokunduğu her satırı kilitleyeceği için, arkadan gelen transaction beklemek zorunda kalır.

2. Serializable Isolation Level kullanılabilir.

DO-332 Object Oriented Technology and Related Techniques Supplement

Giriş

DO-178B Object Oriented geliştirme yönteminden çok daha önce yayınlandığı için isteseydi de OO konularına değinemezdi. Ancak günümüzde OO çok daha fazla kullanılıyor. DO-178C yazılım geliştirme açısından daha fazla Object Oriented yönelimli. Garbage Collection,Virtualization, Generics (template) kullanımı konularına değiniyor.

Bu belge 2011 yılında yayınlandı ve 150 sayfa civarında. 4 tane ANNEX ve 2 tane APPENDIX'ten oluşuyor. ANNEX ve APPENDIX 'in farkının açıklaması şöyle. Dolayısıyla ANNEX'leri tek başına okumak mümkün.

An appendix contains data that cannot be placed in the main document and has references in the original copy or file. An annex, on the other hand, is usually a standalone document that offers additional information than contained in the main document.

Bazı önemli başlılar şöyle

1.0 INTRODUCTION

  1.6 Characteristics of Object-oriented Technology and Related Techniques

  Bu başlık altında genel geçer OO kodlamayla ilgili şeyler var.

  1.6.1.2.1 Liskov Substitution Principle

  Burada kalıtan her sınıfın Liskov prensibine uyması gerektiği belirtiliyor.

2.0 SYSTEM ASPECTS RELATING TO SOFTWARE DEVELOPMENT

Burada yazan şey sadece şöyle. Yani DO-178C belgesini okuyun diyor.

Section 2 of DO-178C is unchanged

3.0 SOFTWARE LIFECYCLE

Burada yazan şey sadece şöyle. Yani DO-178C belgesini okuyun diyor.

Section 3 of DO-178C is unchanged

4.0 SOFTWARE PLANNING PROCESS

Açıklama yaz

5.0 SOFTWARE DEVELOPMENT PROCESS 

Açıklama yaz

6.0 SOFTWARE VERIFICATION PROCESS

Bu bölümdeki alt başlıkların çoğu DO-178C belgesine atıfta bulunuyor. 

  6.3 Software Reviews and Analysis

  Burada review ve analysis arasındaki farkı anlamak önemli. Açıklaması şöyle.

Reviews are qualitative. They typically compare the artifact being reviewed to a standard using a checklist.

Analyses are quantitative. They could be functional analysis, data flow analysis, timing analysis, or other evaluation of the software artifact.

  Belgedeki açıklama şöyle

6.3 Software Reviews and Analyses

Reviews and analyses are applied to the outputs of the software development processes. One distinction between reviews and analyses is that analyses provide repeatable evidence of correctness and reviews provide a qualitative assessment of correctness. A review may consist of an inspection of an output of a process guided by a checklist or similar aid. An analysis may examine in detail the functionality, performance, traceability, and safety implications of a software component, and its relationship to other components within the system or equipment.

7.0 SOFTWARE CONFIGURATION MANAGEMENT PROCESS

Burada yazan şey sadece şöyle. Yani DO-178C belgesini okuyun diyor.

Section 7 of DO-178C is unchanged

Burada bir süreç olduğunu ispatlamak gerekiyor. Açıklaması şöyle. Code Review'ların bir standarda dayandırılması, kodun static kod analizinden geçmesi ve bir issue tracking yazılımının kullanılması gibi şeyleri göstermek gerekiyor.

Configuration management, including change review and problem tracking. If you're following DO-178C you can't merge in an unreviewed code change or hide a bug report

8.0 SOFTWARE QUALITY ASSURANCE PROCESS

Açıklama yaz

9.0 CERTIFICATION LIAISON PROCESS

Açıklama yaz

10.0 OVERVIEW OF CERTIFICATION PROCESS

Açıklama yaz

11.0 SOFTWARE LIFECYCLE DATA

Açıklama yaz

12.0 ADDITIONAL CONSIDERATONS

Açıklama yaz

ANNEX A PROCESS OBJECTIVES AND OUTPUTS BY SOFTWARE LEVEL IN DO-178C

Açıklama yaz

ANNEX B ACRONYMS AND GLOSSARY TERMS

Açıklama yaz

ANNEX C PROCESS OBJECTIVES AND OUTPUTS BY ASSURANCE LEVEL IN DO-278A

Açıklama yaz

ANNEX D VULNERABILITY ANALYSIS

Burada OOT kullanırken çıkabilecek zaafiyetlerden bahsediliyor

D.1 Key Features and Related Techniques

  Burada kodlada çıkabilece beklenmedik yan etkilerden bahsediliyor.

  D.1.1 Inheritance

  D.1.2 Parametric Polymorphism

  D.1.3 Overloading

  D.1.4 Type Conversion

  D.1.5 Exception Management

  D.1.6 Dynamic Memory Management

  D.1.7 Virtualization

D.2 General Issues

  Burada özellikle analiz yöntemlerinden bahsediliyor.

APPENDIX A COMMITTEE MEMBERSHIP

Burada sadece komite üyelerinin isimleri yazıyor.

APPENDIX B FREQUENTLY ASKED QUESTIONS

Açıklama yaz

Apache Kafka API

Giriş 

Kafka API'si başlıklara ayrılmış. Başlıklar şöyle.

Producer API
Consumer API
Streams API
Connector API

API'lerin açıklaması şöyle

1) Producer API: It provides permission to the application to publish the stream of records.
2) Consumer API: This API is being used to subscribe to the topics.
3) Stream API: This Stream provides the result after converting the input stream into the output stream.
4) Connector API: This links the topics with existing applications.

Producer API

Kafka Producer API yazısına taşıdım

Consumer API
Açıklaması şöyle.

The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.

Java örneklerini Kafka Consumer API yazısına taşıdım

Subscribe ve Self Assign Farkı

Consumer API iki farklı şekilde kullanılabilir.

1. Subscribe Olarak

2. Self Assign'ı seçip partition 'a direkt gidip okuyarak 

Subscribe yönteminde Rebalance sorumluluğu Kafka üzerinde. 

Self Assign yönteminde Rebalance sorumluluğu uygulamanın üzerinde

Consumer Config Parametreleri

Consumer Config Parametreleri yazısına taşıdım.

Streams API

Kafka Streams API yazısına taşıdım

ACID - Repeatable Read Seviyesi Nedir ? - Benim Dokunduğum Satırı Kilitler Gibi Düşünülebilir

Giriş

Şeklen şöyle. Üçüncü satırda Repeatable Read görülebilir.

SQL Server için şeklen şöyle

Açıklaması şöyle

It ensures that the same select query will always return the same result, no matter how many times it is executed, even if some other concurrent transactions have committed new changes that satisfy the query.

Transaction içinde kullanılan tüm verinin her seferinde aynı değeri taşıyacak şekilde okunması garanti edilir. 

- Dirty Read problemini engeller. 

- Lost Update problemini engeller.

- Phantom Read problemini engellemez. Benim dokunmadığım satırlar kilitlenmediği için bunlar değiştirilebilir veya yeni satır eklenebilir

- Phantom satır kapsamında Write skew problemini engellemez.

Şeklen şöyle. Burada Transaction 1 başlıyor ve 2 numaralı satırı okuyor, ancak 3 numaralı satıra dokunmuyor. Transaction 2 ise 3 numaralı satırı değiştirip commit'liyor. Transaciton 2 3 numaralı satırı okusa bile eski veriyi görüyor.

Açıklaması şöyle

REPEATABLE READ isolation level guarantees that transactions see the committed view of the database snapshot taken by the first read. Unlike READ COMMITTED isolation level, data that is read at one point in the transaction is the same as data that is read at another point in the transaction.

... The concurrent transactions see the committed view of the snapshot taken within each transaction. Transaction 1 gets charlie, not chris, because Transaction 1 began before Transaction 2. To put it another way, the two concurrent transactions are performed in serial.

Note that the snapshot is taken by the table, not by the row or database. A first read to the table creates a new table snapshot. As to the above diagram, Transaction 1 creates a snapshot of the users table when issuing SELECT name FROM users WHERE id = 2. Once the transaction ends, the snapshot is deleted.

1. Lock Çeşitleri Nedir?

Açıklaması şöyle. Lock çeşitleri yanında lock'ın ne zaman bırakıldığı da önemlidir.

What are the locks in RDBMS?

Shared read lock: When a single row is read, a read lock is held. This allows another transaction from another thread to have a read lock on the same record — but no other transaction from another thread can impose a write lock to update it.

Update lock: When an update lock is held, other threads can only acquire a shared read lock — not update nor an exclusive write lock.

Exclusive write lock: An update lock is promoted to a write lock. I think this promotion is only possible when only one lock, which is this update lock (no other shared read lock), is locking this row. When a write lock holds a row, no other transaction from any other thread can hold any lock on that row.

-Shared read lock aynı anda okumayı engellemez, başkası yazamaz

-Update lock aynı anda okumayı engellemez, başkası yazamaz. Update lock, Exclusive Lock'a yükseltilebilir.

-Exclusive Lock başka herhangi bir lock'a müsaade etmez

2. Repeatable Read Gerçekleştirimi

Repeatable read gerçekleştirimi için iki tane yöntem var. Bunlar şöyle

1. With transaction 1 as Repeatable Read, other transactions can not update a row after it has been selected by transaction 

2. With transaction 1 as Repeatable Read, other transactions can update a row, but transaction 1 does not take into account those changes.

Çoğu veri tabanı 1. yöntemi seçiyor. 

1. Yöntem şu anlama gelir Kullanılan Lock - Okumayı Engellemez Ama Yazmayı Engeller

Repeatable Read "Update Lock" kullanır. Bu lock read committed seviyesinin aksine transaction bitmeden bırakılmaz. Yani bu lock çeşidi ile başkasının benim satırıma yazması engellenir.

SQLServer - 1. Yöntem

Açıklaması şöyle

With transaction 1 as REPEATABLE READ, you cannot update a row in transaction 2 after you selected it in transaction 1.

MYSQL - 2. Yöntem

Açıklaması şöyle

While many database systems will actually behave like your first version, for MySQL, version 2 is the expected behaviour, see the documentation about repeatable read:

Bu yüzden "select ... for update" kullanılıyor. Açıklaması şöyle

In MySQL, if you want to block another transaction from updating the rows in repeatable read, you need to lock them by e.g. using select ... for update. A simple select will not place a lock unless you are in serializable isolation mode.

PostgreSQL - 1. Yöntem

Repetable Read yazısına taşıdım.

Repeatable Read Kullanım Senaryosu Örnekleri

Örnek

Eğer bir mali rapor hazırlıyorsam ve kârı iki farklı yerde gösteriyorsam iki tane SUM cümlesi çalıştırırım. Eğer repeatable read kullanmazsam okuduğum veri güncellenebilir ve iki farklı sonuç elde ederim.

3. Lost Update Çözümü Nasıldır

Örnek

Lost Update için en açıklayıcı senaryo aşağıdaki gibi. İki thread'in aynı anda banka hesabındaki paradan 100 TL çekmeye çalıştığını düşünelim.

•     funds == 100; amount == 100
•     thread A enters withdraw / transaction A starts
•     thread A executes isEnoughFunds which evaluates to true
•     thread B enters withdraw / transaction B starts
•     thread B executes isEnoughFunds which evaluates to true
•     thread A executes decreaseFunds / thread A locks db record
•     thread B waits for thread A to commit transaction and release write lock
•     thread A exits withdraw / transaction A commits
•     thread B executes decreaseFunds / thread B locks db record
•     thread B exits withdraw / transaction B commits
•     funds == -100

Yukarıdaki örnekte para olmadığı halde 100 TL çekilebildi. Eğer Repeatable read kullanırsak B thread'i A'nın işini bitirmesini beklemek zorunda kalır, çünkü satırı güncelleme niyeti ile kilitlemek istediğini bildirecek ancak kayıt zaten A tarafından kilitlendiği için bekleyecektir. Kilidi alınca da ilk transaction commit yaptığı için çekme işlemi gerçekleşmez. Açıklaması şöyle

If two transactions attempt to modify the same record, the second transaction will wait for the first one to either commit or rollback. If the first transaction commits, then the second one must be aborted to prevent lost updates.

4. Select İşlemi - Phantom Read Problemi

Bu problem halen karşımıza çıkabilir

Örnek

Şöyledir

T1 begins

T1Queries select * from Tbl where X>100 → 3 rows

T2 begins

T2 Inserts 1 additional row with X=150.

T2 Commits.

T1 Queries select * from Tbl where X>100 → 4rows [Phantom Read].

5. Diğer Konular

Spring

Spring ile bu isolation level ile transaction başlatmak için aşağıdaki kod kullanılabilir.

@Transactional (isolation=Isolation.REPEATABLE_READ)

Oracle

Oracle bu isolation seviyesini desteklemez. Açıklaması şöyle.

REPEATABLE READ; Oracle does not normally support this isolation level, except as provided by SERIALIZABLE.

Vitess

Çoğu sharded veri tabanı gibi "Cross Shard" işlemlerde Repeatable Read seviyesi desteklenmez

Scrum - Product Backlog (Ürün Biriktirme Listesi) - Bu Kod Seviyesinde Bir Backlog Değildir

Giriş
Scrum'da 3 tane önemli yapı/çıktı var. Bunlar şöyle.

- product backlog,
- sprint backlog,
- sprint goal.

Backlog kelimesi "Biriktirme Listesi" olarak tercüme ediliyor. Ben bu yazıda backlog kelimesini kullanmayı tercih ettim.

Backlog'dan Ne Zaman Bir Şey Silinir
Artık o iş yapılmamaya karar verince silinir. Açıklaması şöyle. İşin çok sonraya ötelenmesi backlog'dan silinmesine gerekçe değildir.

For me, the only reason to delete (close) an item in the backlog is because you decide it will never be implemented, not because it won't be implemented for a while

Product Backlog'un Sahibi Kimdir ve Kim Önceliklendirme Yapar
Backlog'a girecek,çıkacak şeylere ve önceliklendirmeye normalde Product Owner karar verir. Açıklaması şöyle. Yani Product Backlog, Product Owner tarafından yapılması istenen herşeyi içerir.

the Product Owner is the person who has full authority of determining what goes in and comes out of the product backlog. 

Açıklaması şöyle

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

- Clearly expressing Product Backlog items;

- Ordering the items in the Product Backlog to best achieve goals and missions;

- Optimizing the value of the work the Development Team performs;

- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,

- Ensuring the Development Team understands items in the Product Backlog to the level needed.

PO'nun önceliklendirmesi bazı yerlerde uygulanmıyor. Açıklaması şöyle

Where I have worked previously, the PO owned the backlog, and the Product Manager would prioritize the backlog. 

Backlog User Story Şeklinde Olmalı

Açıklaması şöyle.

The product backlog includes features to be built, enhancements, fixes, quality attributes, etc. in the form of user stories.

Backlog Hazırlığı
Backlog geliştirme ekibinden önce gitmeli. Açıklaması şöyle.

Preparing the backlog well ahead of the next sprint(s) is a must.  You never want the team to run out of work to do, and that work must be of highest value at that point in time as prioritized by the Product Owner.  Being a Product Owner can be time-consuming.

Backlog'u Sırayla İşlemek - Pipeline
Backlog bir pipeline haline dönüştürülebilir. Buradaki soruda önce ekranların bitirilip sonra arkalarının doldurulması anlatılmış. 

Sıralama
Backlog sıralı bir şekilde tutulur. Açıklaması şöyle. Sıralama (ordering) ve önceliklendirme (prioritizing ) farklı şeyler

The Scrum Guide does not talk about prioritizing the Product Backlog. Instead, it talks about ordering the Product Backlog. Priority is only one factor that can be used to determine the ordering of the Product Backlog. Dependencies between work items is another factor, but the Product Owner can choose any factors that are appropriate to help maximize the delivery of value.

Sıralamada dikkat edilmesi gereken noktalar şöyle. Yani en fazla fayda getirecek maddeleri önce alıp en fazla verimi almaya çalışmak.

- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;

Sıralama Ölçütünde Dikkate Alınabilecek Şeyler 

1. Yazılım Hataları
Eğer yazılımda bir hata varsa sıralamanın belirlenmesinde gravity ve frequency katsayıları kullanılabilir. Açıklaması şöyle.

Generally you have two axes for bugs: gravity and frequency.

So obviously something grave and frequent is of the highest priority. However, something that's serious but happens rarely should be weighed roughly at the same as something that's not serious but happens often. So supposing you rate gravity from 1 to 3 and frequency from 1 to 3, the types of bugs you should probably be fixing are those which cross the diagonal defined by gravity 1, frequency 3, and gravity 3, frequency 1.

2. Müşteri Tarafından Raporlanan Hatalar

Soru şöyle

When a user reports a bug should it go directly to the programmer or should it go to qa first and must be reproduced by qa before going to the programmer?

Cevap şirketine göre değişir. Eğer Product Owner üzerinden gidilecekse, açıklaması şöyle.

It depends on your policy if you have one. It could go either way.

It could also be that it goes to the PO and they should approve it before continuing with the fix or putting it in the backlog.

3. Uzmanlık Alanı

Burada ekipteki uzmanlık alanı gerektiren şeyleri yapabilecek insan sayısına dikkat etmek gerekir. Eğer sırası gelen işi yapabilecek insan müsait değilse çözüm olarak şu iki şeyden birisi yapılabilir. Açıklaması şöyle. Ya herkesi uzman yapmak gerekir. Ya da backlog'daki bir sonraki işi sprint'e almak gerekir.

This is where the Development Team and Product Owner need to come to some level of understanding and agreement on how to proceed.
- One option is to do what the Development Team is doing now - everyone focuses on their particular strength if they have the capacity, even if the work they take is not the next most important.

- The other option is to work on developing the skills of the Development Team members so that everyone is more capable of taking on any piece of work.

Yazılım Mimarisi - Monolithic Architecture (Tek Parça/Yekpare Mimari)

Giriş

Günümüz dünyasında microservice mimarisinin o kadar fazla reklamı yapılıyor ki, sanki tüm eski mimariler ve yaklaşımlar çöpmüş gibi düşünülüyor.

Aslında bu yazılımlar da çalışıyordu ve iş görüyordu. Eğer yukarıya doğru ölçeklendirme problemi yoksa bu mimariler halen daha kullanılabilir şeyler.

Monolithic Architecture Arap Saçı (Big Ball of Mud) Değildir

Big ball of mud yazılımlar aslında mimariden bağımsızdır. Microservice mimari kullanan çamur topu yazılımlar da olabilir. Aslında Monolithic mimarinin bu keşmekeş olmasının sebeplerinden birisi global nesnelerin çok fazla kullanılması olabiliyor. İşlevsel olarak bölünmüş (modular) yapı ile bölünmemiş yapı aradaki farkı gösteren bir şekil burada. Modular olmayan yapıda bir bileşeni bir sürü farklı alt modül de kullanıyor. Bileşende yapılan bir değişiklik bir sürü yeri de etkiliyor.

Proje Yapısı

Tek parça yazılımlar genellikle şu yapıdadır. Burada catalog, delivery, order modülleri temsil eder. application altında da uygulamayı ilgilendiren şeyler vardır

myshop/

+- application/

+- catalog/

+- delivery/

+- order/

...

Microservice mimariye geçince yapı şuna benzer. Burada her service bağımsız bir uygulama gibi olduğu için kendi altında gerekli şeyleri toplamıştır. 

myshop/

+- catalog/

|  +- application/

|  +- domain/

|  +- jdbc/

|  +- rest/

|  \- spring-boot-starter/

+- delivery/

|  +- application/

|  +- domain/

|  +- events/

|  +- jdbc/

|  +- rest/

|  \- spring-boot-starter/

+- order/

|  +- application/

|  +- domain/

|  +- events/

|  +- jdbc/

|  +- rest/

|  \- spring-boot-starter/

...

Monolith Yapıdan Microservice Yapıya Geçmek

Monolith Yapıdan başka bir yapıya geçmeye başlamadan önce ilk yapılması gereken şey kimilerinin "Horizontal Layering", kimilerinin de "Domain" dedikleri yapıyı çıkartmak. Bu yapı şeklen şöyle

Dikey yapı yani Vertical Layering genellikle daha anlaşılır oluyor, ancak Domain'leri çıkartmak veya kimin kiminle yatay olarak iletişim kurduğunu çıkartmak daha zor ve her şeyden önce bu mutlaka yapılmalı

Şeklen şöyle

Ortak Kullanılan Kendi Kütüphanelerimiz - Shared Custom Library

Ortak kullanılan kendi kütüphanelerimiz olsun diyenler ve olmasın diyenler diye iki grup var.

1. Eğer varsa kütüphaneler mutlaka sürüm numarasın ile kullanılmalı

2. Eğer ortak kütüphane istemiyorsak, kütüphane kodlarını bir servise taşımak ta bir diğer çözüm

Monolith Yapıdan Microservice Yapıya Geçmek

Bu iş için Strangler (Sarmaşık) Örüntüsü kullanılabilir. Açıklaması şöyle