Yazılım mühendisleri için davranışsal görüşme soruları (Behavioral Interviews: for Software Engineers)

 Merhaba bu yazımda sizlere, teknik mülakattan önce işveren için adayı tanıma konusunda yol gösterici olan, davranışsal interview sorularına biraz kendi mesleki hayatımdan ve bazen kurgusal olarak örnekler vermeye çalışacağım.

Davranışsal görüşmede nasıl başarılı olunur?

1) Hazırlıksız gelme

Size hangi davranışsal mülakat sorularının sorulacağını önceden bilemezsiniz. Bununla birlikte, her zaman yaptığınız gibi yine de bir röportaj için hazırlanmanız gerekir. Aksi takdirde, mülakatı yapan kişide en iyi izlenimi bırakmadan kendi sözlerinizle ya da aklınıza gelen ilk şeyi söyleyerek mırıldanırsınız.

Şirketi araştırmaya ek olarak, büyük mesleki başarılarınızı ve zorluklarınızı hatırlamak için zaman ayırın. Hatta bunları bir yere yazabilirsiniz, böylece işe alma müdürü size başarılı ekip çalışması örneklerini sorarsa, zaten bir cevabınız oluşmuş olur.

2) STAR yaklaşımını kullanın

Kariyer danışmanları, STAR yaklaşımının davranışsal mülakat sorularına yanıt vermenin etkili bir yolu olduğunu belirtmektedir. Bilgilendirici ve kapsamlı bir cevap vermek için izlemeniz gereken belli bir yapıyı ifade eder.

- S (Situation) - durum - içinde çalışmanız gereken bağlamı ana hatlarıyla belirtin;

- T (Task) - görev - tamamlamanız gereken görevi, çözmeniz gereken sorunu veya belirlenen hedefi tanımlayın;

- A (Action) - eylem - yukarıda belirtilen görevi tamamlamak için gerçekleştirdiğiniz belirli eylemleri anlatın;

- R (Result) - sonuç - eylemlerinizle hangi sonucu başardığınızı açıklayın.

STAR tekniği neden işe yarıyor? Sadece konunun etrafında dolaşmadan odaklanmış bir cevap vermenize yardımcı olmakla kalmaz, aynı zamanda hedefe ulaşmak için hangi becerileri uyguladığınızı göstermenize de olanak tanır.

3) Rakamları ve gerçek olayları kullanın

STAR yaklaşımına göre hikayeyi anlatırken, onu kesin rakamlar ve belirli sonuçlarla enjekte edin. Ayrıca ünlü müşterinin veya sektörde etkili bir kişi olan patronun adını da bırakabilirsiniz. "Tanıttığım yeni yönetim tekniği ile zamandan tasarruf ettik" demek yerine, "Ekip görevleri% 10 daha hızlı tamamlamaya başladı" deyin. Gerçekler, sonuçlara odaklanmanızı ve güvenilir bir şekilde inşa ettiğinizi gösterir.

4) Kültürel uyumunuzu gösterin

Görüşme için hazırlanırken, web sitesini, sosyal medya sayfalarını ve orada çalışan kişilerin hikayelerini kullanarak şirketin kurumsal kültürünü araştırın. İşe alan kişinin sorularını yanıtlarken, mükemmel bir kültürel uyum olarak karşımıza çıkmak için farklı açılardan yararlanın. Örneğin, şirket bireyselliği ve rekabeti teşvik ediyorsa, stresi kendi katkınıza ve çabalarınıza koyun. Şirket ekip çalışmasına değer veriyorsa, içinde çalıştığınız ekibin başarısını gösteren hikayeleri anlatın.

5) Vücut diliniz üzerinde çalışın

Daha önce beden dilinin ve sözlü olmayan sinyallerin önemini duyduğunuzu biliyoruz. Ancak, tekrar edilmeye değer. Mesele şu ki, omuzlarınız devrilmiş ve bacak bacak üstüne atılmış olarak otururken kendinizi harika bir müzakereci ve en iyi performans gösteren biri olarak tanımlarsanız, görüşmeci tutarsız bir izlenim edinir. Bu yüzden mülakat anlaşması için ipuçları bile çok önemlidir.

Ünlü bir yaşam koçu Antony Robbins, daha güvenli görünmek ve hissetmek için "güçlü poz verme" yi öneriyor. Ofise girmeden önce, 2 dakika Süpermen gibi ellerinizi kalçalar üzerinde tutun. Bu pozu almak testosteron seviyenizi% 20 artırır ve stresi azaltır.

6) Negatif olmaktan kaçının

Görüşmenin yalnızca başarılarınızı kapsaması pek olası değildir. Görüşmeci, çatışmaları, zor durumlardaki çözümünüz ve başarısızlıkları nasıl ele aldığınızı görmek isteyecektir (bu arada, konuyla ilgili bazı uzman tavsiyelerini burada bulabilirsiniz: http://resumeperk.com/blog/conflicts-at-work-most-common-types),  Dolayısıyla, muhtemelen müşteriden bir şikayet aldığınızda, projeyi zamanında teslim edemediğinizde veya iş için maliyetli olduğu ortaya çıkan bir hata yaptığınızda durum size sorulacaktır. "Asla hata yapmam" gibi bir şeye yanıt vermekten kaçının. Bu durumda hata yaptığınızı veya yanlış davrandığınızı kabul etmelisiniz, ancak durumdan öğrendiğiniz derslere odaklanmalısınız. Örneğin bilgi eksikliğinden dolayı bir hata yaptıysanız ileride bu tür hatalardan kaçınmak için kurumsal eğitim aldığınızı belirtebilirsiniz.

7) Önemsenecek noktalarınızı öğrenin ve bunları gösterin

Uzmanlar, ödevinizi yaparken sizi benzer niteliklere sahip adaylardan ayıran üç ana özelliği yazmanızı tavsiye ediyor. Örneğin, başkalarının tavsiye almak için başvuracağı bir kişi olmanız ya da  pazarlama girişimleri sunan gerçekten yetenekli bir iletişimci olabilmeniz gibi. 

Doğru soru ortaya çıktığında bu yetkinliklerden bahsedin. Davranışsal soruların doğru ya da yanlış cevapları olmadığından, düşüncelerinizi bir araya getirmek için birkaç saniyenizi ayırmanız sorun değildir (nefes alabilir veya biraz su yudumlayabilirsiniz).

Davranışsal sorular ve cevaplar ingilizce olacak, ayrıca Türkçe açıklama ve çeviriler eklenecektir.

01. Tell me about one of the most technically challenging projects you have done.

(Bitirmiş olduğunuz, teknik olarak en zorlu projelerden birini anlatın.)

Answer: Most of the projects that I was involved in were technically challenging. But if I had to choose one I would say Digital Agency Project in Anadolu Sigorta was the most challenging. When we started this project, the technologies we were using were just becoming popular in 2017 (Jhipster, Spring Boot, Angular 4, Elasticearch, Yarn, Liquebase, Mapstruct) and we didn't have too much knowledge about these technologies and we had to integrate them with Anadolu Sigorta SOA services. The project domain was also complex.

02. Tell me about one of your failed projects. What did you learn? What could you do differently?

(Bana başarısız projelerinizden birini anlatın. Ne öğrendin? Neyi farklı yapabilirdin?)

Answer: I can give an example of a big task of a project where things didn't go exactly the way I wanted. In Garanti Investment web project financial dictionary implementation was an important part of the project. I was not as well skilled at javascript as backend technologies. And I didn't have a lot of knowledge of clean code nor was I aware of its importance. I successfully finished the dictionary implementation, but it took too long and it hadn't been implemented with clean code principles and effective way. Our team leader decided to implement it from the scratch by himself.

After that completion of the task, I realized the importance of clean code and writing effective javascript code.

03. Tell me about the project that you are most proud of. What was the most significant accomplishment of your entire career?

(Bana en çok gurur duyduğun projeden bahset. Tüm kariyerinizin en önemli başarısı neydi?)

Answer: If had to choose one I would say the project I am most proud of was emlakjet.com rebuilding project. We analysed the legacy project, understood the domain, migrated the database from MySQL to PostgreSQL, implemented the project with the modern framework, and completed the project successfully before the deadline.

04. Tell me about a time that you found a creative solution to a problem.

(Bana bir soruna yaratıcı bir çözüm bulduğunuz zamanı anlatın.)
Answer: In my last project RiskMobile, we had performance and memory issues. We came up with some solutions for these :
Increased free heap memory space by up to %50 calculating report String size before transforming base64 StringBuilder.
Increased report photo upload speed by up to %80 using the parallel upload.
An increased report read time up to %80 by lazy loading.

05. Tell me about a time when you had a conflict with your teammate or manager: how did you resolve it, and what did you learn?

(Takım arkadaşın veya yöneticinle bir çatışma yaşadığın bir zamandan bahset: Bunu nasıl çözdün ve ne öğrendin?)

Answer: Usually, conflicts happen between analysts and developers. In such cases, I have a private conversation with the analyst to try to understand him/her and tell him/her about my task-related dilemmas. I try to find a solution together without making it a personal issue.

06. Tell me about a time that you were behind on a project and you knew that you could not meet the deadline. Tell me about a time when you changed priorities to meet a deadline.

(Bana bir projede geride kaldığınız ve son teslim tarihine yetişemeyeceğinizi bildiğiniz bir zamandan bahsedin. Son teslim tarihine uymak için önceliklerinizi değiştirdiğiniz bir zamandan bahsedin.)

Answer: In a new version of the Alcatel OSOS project, we had defects to solve and new features to add. Towards the end date, we were far behind these goals. We have postponed less critical new features to the next version and put it first to solve problems that matter to the customer. After solving the problems, we applied the most valuable new features and successfully released the version.

07. Tell me about a time that you had to implement a workaround (vs. a solution) for a critical issue to meet a deadline and as a result, you introduced technical debt. What did you do with the technical debt after the deadline?

(Son teslim tarihini karşılamak için kritik bir sorun için bir geçici çözüm (çözüm yerine) uygulamak zorunda olduğunuz ve bunun sonucunda teknik borç getirdiğiniz bir zamandan bahsedin. Son teslim tarihinden sonra teknik borcunuzla ne yaptınız?)

Answer:We are developing a complex feature for an e-commerce platform - an advanced search system that uses machine learning algorithms to predict and suggest user interests.

A few days before the deadline, we discover a significant issue. The machne learning model isn't training correctly, and resolving the problem would require considerable time for debugging, retraining, and validation - time we don't have.

With the deadline fast approaching, we decide to implement a workaround: instead of using the machine learning model, we develop a simpler rule-based system for the search feature. While it's not as accurate or efficient, it serves the purpose for the time being, and we manage to ship the feature on time. However, this creates technical debt in our codebase - we now have a less optimal feature that will need to be upgraded in the future.

After the deadline has passed, we don't ignore the technical debt we've accrued. We understand that while the workaround was necessary at the time, it's not a sustainable or long-term solution. We discuss the matter with the project manager and propose a plan to repay this debt. The plan includes:

Identifying the Problem: We document the details of the technical debt, its cause, and what parts of the system it affects.

Planning the Solution: We design a strategy for fixing the ML model issue. This involves debugging the problem, implementing the fix, retraining the model, and validating its results.

Scheduling: We plan out a timeline for the work, considering other project requirements and deadlines.

Implementation: We work on the issue according to the schedule, replacing the rule-based system with the intended machine learning model.

Testing and Verification: We rigorously test the new system to ensure it works as expected and improves upon the old system.

Documentation: We update all relevant documentation to reflect the changes made and document the lessons learned to prevent a similar occurrence in the future.0

8. Why do you want to leave your current job? Could you mention some general issues in your current job? Have you taken any action to mitigate/resolve those issues? 

(Mevcut işinizden neden ayrılmak istiyorsunuz? Şu anki işinizle ilgili bazı genel sorunlardan bahsedebilir misiniz? Bu sorunları hafifletmek / çözmek için herhangi bir önlem aldınız mı?)

Answer:"I have had a rewarding journey at my current company and I've learned a lot, but I believe it's time for me to take on new challenges and further develop my skill set. There are a few reasons behind my decision to look for a new opportunity.

One ofthe main issues has been the limited opportunities for growth and advancement in my current role. I have a deep interest in working with emerging technologies like artificial intelligence and machine learning, but my current job does not provide the space to explore these areas. I value continuous learning and professional development, and unfortunately, it's been challenging to find those opportunities in my current role.

Another factor has been the lack of balance between work and personal life. I understand that there will be times when extra hours are necessary, especially in software development, but it has become a consistent trend rather than the exception. This has, in turn, affected my work-life balance.

I've certainly taken steps to address these issues. Regarding the growth opportunities, I've tried to incorporate learning into my personal time and have taken online courses to stay abreast with the latest technologies. However, this doesn't provide the same benefits as practical, on-the-job experience would.

In terms of the work-life balance issue, I've had open discussions with my team lead and manager about it. We've tried to distribute workload more evenly and hire additional team members to manage the workload. But the pace of the company and the resource constraints have made it difficult to bring about substantial change.

Given these circumstances, I believe it would be beneficial for my career and personal growth to explore new opportunities where I can leverage my skills and passion for emerging technologies, while also maintaining a healthier work-life balance. I'm excited about the opportunities that your company provides in both these aspects."

09. Why do you want to join us? What do you know about our company?

(Neden bize katılmak istiyorsun? Şirketimiz hakkında ne biliyorsun?)

Answer:  "I'm really impressed with your company's reputation for innovation and commitment to using the latest technologies to create impactful products. As an engineer passionate about working with cutting-edge technology, it's exciting to see the breadth of projects your team takes on.

Your company's focus on artificial intelligence and machine learning, for instance, is particularly appealing to me. In my previous role, I didn't get much opportunity to explore these areas, and I'm eager to dive into this field. I've taken some online courses and done personal projects, but working with your team would provide a more in-depth, practical experience that I am looking for.

I've also read about your company's emphasis on maintaining a healthy work-life balance for your employees. This aligns with my personal values and my belief in the importance of a balanced lifestyle for productivity and creativity.

I'm also aware of your company's strong commitment to giving back to the community, which I find admirable. I appreciate that you go beyond just doing business and strive to make a positive impact in society.

Furthermore, your company culture, which encourages collaboration, continuous learning, and innovation, is very appealing. I believe this kind of environment will help me grow as a professional and contribute more effectively to the team.

In summary, I want to join your company because I believe it aligns with both my professional goals and personal values. I'm excited about the prospect of contributing to and learning from a team that's pushing boundaries in technology, all while maintaining a sustainable work-life balance and making a positive impact on the community."

10. If you have worked in many companies for short periods of time (< 2yrs), why do you switch your jobs so frequently?

(Kısa süreler için (<2 yıl) birçok şirkette çalıştıysanız, neden işlerinizi bu kadar sık değiştiriyorsunuz?)

Answer:"I appreciate your concern about the frequency of job changes in my history. I believe it's crucial to clarify that these changes were not made lightly, but were carefully considered steps in my career progression.

Early in my career, I had the opportunity to work in different start-ups, each offering unique projects and technologies. These opportunities allowed me to broaden my skill set and understand various facets of software engineering. My goal was to gain diverse experience in a relatively short amount of time, and these roles offered me the chance to do just that.

In a couple of instances, the startups I was working for underwent significant changes, such as acquisition or restructuring, which led to my decision to move on sooner than anticipated.

While it may seem that I've moved jobs frequently, each move was a strategic decision to broaden my knowledge base, increase my experience with different technologies and industries, and adapt to unforeseen circumstances.

I've always made sure to leave on good terms, having delivered significant contributions and after ensuring a smooth transition. I believe the varied experiences have made me more adaptable, versatile, and capable as a software engineer.

Having said that, I am now looking for a longer-term opportunity where I can grow deeper roots, continue to learn and contribute significantly. Your company, with its innovative projects and stability, seems like an excellent fit for this next phase of my career."

11. What is your weakness?

(Zayıf yönün nedir?)

Answer:"I think one of my weaknesses has been overcommitting myself. I am very passionate about my work and I tend to get excited about new projects or challenges, so sometimes I take on more tasks than I should. This can lead to longer hours and increased stress levels as I strive to deliver on all my commitments.

However, I've been working actively to improve in this area. I've started using project management tools and techniques to better manage my workload, and I'm becoming more conscious about the commitments I take on. I've also been learning to delegate effectively and have open discussions with my team and superiors about workload distribution and deadlines.

Recognizing this weakness has been a valuable realization for me, and while I am still a work in progress, I am committed to continuing to improve my time management and workload balancing skills. This self-improvement will not only increase my productivity but also maintain the quality of work I am known for."

12. What is your strength?

(Güçlü yönün nedir?)

Answer: I believe that my greatest strength is the ability to solve problems quickly and efficiently. I can see any given situation from multiple perspectives, which makes me uniquely qualified to complete my work even under challenging conditions. That problem solving allows me to be a better communicator. I am just as comfortable speaking to senior executives as I am junior team members. I think my ability to see all sides of an issue will make me a great asset to the team.

13. What is your current salary, or what is your salary expectation?

(Mevcut maaşınız veya maaş beklentiniz nedir?)

Answer:

14. What does your typical day look like at your current job?

(Mevcut işinizde tipik bir gününüzü nasıl geçirirsiniz?)

Answer:

15. Describe one of the biggest mistakes you have made in your job, and what did you learn?

(İşinizde yaptığınız en büyük hatalardan birini anlatın ve bu hatadan ne öğrendinizi söyleyin?)

Answer:

16. Describe a situation in which you were faced with a major obstacle in order to complete a project. How did you deal with it? What steps did you take?

(Bir projeyi tamamlamak için büyük bir engelle karşı karşıya kaldığınız bir durumu anlatın. Bununla nasıl başa çıktın? Hangi adımları attın?)

Answer:

17. How do you solve ambiguous problems?

(Belirsiz sorunları nasıl çözersiniz?)

Answer:

18. How do you see yourself in five (or ten) years? What skills do you want to learn?

(Kendinizi beş (veya on) yılda nasıl görüyorsunuz? Hangi becerileri öğrenmek istiyorsun?)

Answer: In several years, I see myself involved in architecting complex Java applications. Beyond that is too far away to think of right now.

19. Tell me about a time that you supervised/trained other engineers.

(Bana diğer mühendisleri denetlediğiniz / eğittiğiniz bir zamandan bahsedin.)

Answer:

20. Tell me about a time that you changed or improved the culture of your company or team.

(Şirketinizin veya ekibinizin kültürünü değiştirdiğiniz veya geliştirdiğiniz bir zamandan bahsedin.)

Answer:

21. Tell me about a time that you took the initiative.

(Bana inisiyatif aldığınız bir zamandan bahsedin.)

Answer:

22. Do you read any related blogs?

(İlgili herhangi bir blog okuyor musunuz?)

Answer:

23. Describe a time when you made a suggestion to improve something within the project that you were working on.

(Üzerinde çalıştığınız proje içinde bir şeyi iyileştirmek için bir öneride bulunduğunuz bir zamanı anlatın.)

Answer:

24. Give me an example of a time when you noticed a small problem before it turned into a major one. Did you take the initiative to correct it? What kind of preventive measures did you undertake?

(Küçük bir problemi büyük bir problem haline gelmeden önce fark ettiğiniz bir zamana örnek verin. Düzeltmek için inisiyatif aldınız mı? Ne tür önleyici tedbirler aldınız?)

Answer:

25. How will you adjust yourself in a fast-paced environment?

(Hızlı tempolu bir ortamda kendinizi nasıl ayarlarsınız?)

Answer:

26. What is your learning process like? How do you learn new skills?

(Öğrenme süreciniz nasıl? Yeni becerileri nasıl öğrenirsiniz?)

Answer:

27. What don’t you like in a job?

(Bir işte neyi sevmezsin?)

Answer:

28. When do you consider a project to be successful?

(Bir projenin ne zaman başarılı olduğunu düşünürsünüz?)

Answer:

29.Tell me about a time when you had to present a complex programming problem to a person that didn’t understand technical jargon. How did you ensure that the other person understood you?

(Bana teknik jargonu anlamayan bir kişiye karmaşık bir programlama problemi sunmanız gereken bir zamandan bahsedin. Diğer kişinin sizi anladığından nasıl emin oldunuz?)

Answer:

30.Tell me about a time you had to work on several projects at once. How did you handle that?

(Aynı anda birkaç proje üzerinde çalışmanız gereken bir zamandan bahsedin. Bunu nasıl hallettiniz?)

Answer:

31.Describe a situation in which you have experienced a significant project change that you weren’t expecting. What was it? How did that impact you, and how did you adapt to this change? How did you remain productive through the project?

( Beklemediğiniz önemli bir proje değişikliği yaşadığınız bir durumu açıklayın. Bu neydi? Bu sizi nasıl etkiledi ve bu değişime nasıl uyum sağladınız? Proje boyunca nasıl üretken kaldınız?)

Answer:

32.Tell me about a time when you had to work with a difficult person to accomplish a goal. What was the biggest challenge? How did you handle it?

(Bir hedefe ulaşmak için zor bir insanla çalışmanız gereken bir zamandan bahsedin. En büyük zorluk neydi? Bunu nasıl hallettin?)

Answer:

Kaynaklar : CRACKING THE BEHAVIORAL INTERVIEWS FOR SOFTWARE ENGINEERS, FIRST EDITION ,  https://devskiller.com/45-behavioral-questions-to-use-during-non-technical-interview-with-developers/ ,  https://resumeperk.com/blog/behavioral-interview-questions---and-how-to-answer-them 

1- Strategic Domain-Driven Design - vaadin.com - Petter Holmström - Çevirsi

"Bu makale dizisinde, Domain Driven Desgin (domaine dayalı tasarım)'ın ne olduğunu ve projenize - veya bir kısmının - projelerinize nasıl uygulanacağını öğreneceksiniz." diyor Petter Holmström. Ben de elimden geldiğince bu yazı dizisini Türkçe'ye çevirmeye çalışacağım. Umarım İngilizce okumada zorluk çeken arkadaşlar için yararlı olur.



Yazı Dizisinin Orjinali
Örnek DDD projesi

Serinin diğer yazıları :
2 - Tactical Domain Driven Design (Taktiksel DDD)
3 - Domain-Driven Design and the Hexagonal Architecture (DDD ve Altıgen Mimari)

1 - Strategic Domain-Driven Design

(Stratejik DDD)

Domaine Dayalı Tasarım (DDD) Eric Evans'ın konuyla ilgili kitabını 2003'te yayınladığından beri var. Birkaç yıl önce veri tutarlılığı sorunları olan bir projeye katıldığımda DDD ile haşır neşir oldum. Veritabanında tekrarlanan veriler ortaya çıktı, bazı bilgiler hiç kaydedilmedi ve her yerde ve her zaman iyimser kilitleme hatalarıyla karşılaşabileceğimi gördüm. Taktiksel DDD tasarımın yapı taşlarını kullanarak bunu çözmeyi başardık.

O zamandan beri Domaine Dayalı Tasarım (DDD)  hakkında daha fazla şey öğrendim ve bunu projelerimde uygun olan yerlerde kullanmaya çalıştım. Bununla birlikte, diğer geliştiricilerle konuştuğum geçtiğimiz yıllarda, birçoğu domaine dayalı tasarım terimini duydu, ancak bunun ne anlama geldiğini bilmiyorlar. Bu makale dizisinde, gördüğüm ve anladığım şekliyle Domaine Dayalı Tasarım (DDD) a kısa bir giriş yapacağım. İçerik büyük ölçüde Eric Evans'ın Domain-Driven Design: Tackling Complexity in the Heart of Software ve Implementing Domain-Driven Design kitaplarına dayanıyor. Ancak her şeyi kendi sözlerimle açıklamaya ve kendi düşüncelerimi, görüşlerimi ve deneyimlerimi de aşılamaya çalıştım.

Makale dizimi okuyarak Domaine Dayalı Tasarım (DDD)  konusunda uzman olmayacaksınız, ancak umarım bu konu hakkında daha fazlasını başka yerlerde okumanız için size ilham verir. Ayrıca Evans ve Vernon'un kitaplarını okumanızı şiddetle tavsiye ediyorum.

Şimdi ilk konuya, yani stratejik Domaine Dayalı Tasarım (DDD) 'a başlayalım.

Domain(Etki Alanı) nedir?

MacBook'umdaki Sözlük uygulamasında domain'in kelime ararsam aşağıdaki tanımı alırım:

[A] n belirli bir hükümdar veya hükümetin sahip olduğu veya kontrol ettiği bölge bölgesi…

• belirli bir faaliyet veya bilgi alanı ...

- Apple Sözlüğü

Domaine Dayalı Tasarım (DDD) söz konusu olduğunda, bizim ilgilendiğimiz tanımın ikinci kısmıdır. Bu durumda, faaliyet bir organizasyonun yaptığı şeydir ve bilgi, organizasyonun nasıl yaptığıdır. Alan konseptine organizasyonun faaliyetlerini yürüttüğü ortamı da ekleyeceğiz.

Subdomains (Alt alanlar)

Alan kavramı çok geniş ve soyuttur. Daha somut ve elle tutulur hale getirmek için, onu alt alan adı verilen daha küçük parçalara ayırmak mantıklıdır. Bu alt domainleri bulmak her zaman kolay bir şey değildir ve eğer yanlış yaparsanız, bulmacanızdaki parçalar birden bire birbirine tam oturmadığında yolun yarısında sorun yaşayabilirsiniz.

Alt domainleri aramaya başlamadan önce, alt domain kategorileri hakkında düşünmelisiniz. Tüm alt alanlar üç kategoriye ayrılabilir:

1. Çekirdek alanlar (Core Domains)
2. Destekleyen alt alanlar (Supporting Subdomains)
3. Genel alt alanlar (Generic Subdomains)

Bu kategoriler yalnızca alt alan adlarınızı bulmanıza yardımcı olmakla kalmaz, aynı zamanda geliştirme çabalarınızı önceliklendirmenize de yardımcı olur.

Bir organizasyona özel ve diğer organizsasyonlardan farklı kılan şey çekirdek alan adıdır. (core domain) Bir organizsayon, core domnainde olağanüstü derecede iyi olmadan başarılı olamaz (hatta var olamaz). Core domain çok önemli olduğu için, en yüksek önceliği, en büyük çabayı ve en iyi geliştiricileri alması gerekir. Daha küçük alanlar için yalnızca tek bir core domain tanımlayabilirsiniz, daha büyük alanların birden fazla alanı olabilir. Core domain'in özelliklerini sıfırdan oluşturmaya hazırlıklı olmalısınız.

Destekleyen bir alt alan  (Supporting Subdomains), kuruluşun başarılı olması için gerekli olan, ancak core domain kategorisine girmeyen bir alt alan adıdır. Genel değildir çünkü söz konusu organizasyon için hala bir miktar uzmanlaşma gerektirir. Mevcut bir çözümle başlayabilir ve onu ince ayarlayabilir veya özel ihtiyaçlarınıza göre genişletebilirsiniz.

Genel bir alt alan adı  (Generic Subdomains), kuruluşa özel herhangi bir şey içermeyen ancak yine de genel çözümün çalışması için gerekli olan bir alt alan adıdır. Genel alt alan adlarınız için hazır yazılımları kullanmaya çalışarak zamandan ve işten tasarruf edebilirsiniz. Tipik bir örnek, kullanıcı kimliği yönetimi olabilir.

Organizsayonun ne yaptığına bağlı olarak aynı alt alan adının farklı kategorilere girebileceğini belirtmek gerekir. Kimlik yönetimi konusunda uzmanlaşmış bir şirket için kimlik yönetimi core bir alandır. Bununla birlikte, müşteri ilişkileri yönetimi konusunda uzmanlaşmış bir şirket için kimlik yönetimi, generic bir alt alan adıdır.

Son olarak, tüm alt alan adlarının, hangi kategoriye girdiklerine bakılmaksızın genel çözüm için önemli olduğuna dikkat çekmek önemlidir. Bununla birlikte, farklı miktarlarda çaba gerektirirler ve aynı zamanda farklı kalite ve eksiksizlik gereksinimlerine sahip olabilirler.

Misal

Küçük klinikler için bir EMR (Elektronik Tıbbi Kayıtlar) sistemi oluşturduğumuzu varsayalım. Aşağıdaki alt alanları belirledik:

1. Hasta tıbbi kayıtlarını yönetmek için Hasta Kayıtları(Patient Records) (kişisel bilgiler, tıbbi geçmiş, vb.).
2. Laboratuvar testleri sipariş etmek ve test sonuçlarını yönetmek için laboratuar(Lab).
3. Randevuları planlamak için planlama(Scheduling ).
4. Hasta kayıtlarına (farklı belgeler, röntgen resimleri, taranmış kağıt belgeler gibi) eklenmiş dosyaları depolamak ve yönetmek için Dosya Arşivi (File Archive).
5. Doğru kişilerin doğru bilgilere erişimini sağlamak için Kimlik Yönetimi (Identity Management).

Şimdi, bu alt alanları nasıl sınıflandırabiliriz? En bariz olanlar, açıkça genel alt alanlar olan dosya arşivi ve kimlik yönetimidir. Peki ya diğerleri? Bu, bu özel EMR sistemini piyasadaki diğerleri arasında öne çıkaran şeyin ne olduğuna bağlıdır.

Bir EMR sistemi kurduğumuz için, hasta kayıtlarının temel bir alan olduğunu varsaymak oldukça güvenlidir. Akıllı ve yenilikçi zamanlama yoluyla tüm kliniklerin daha verimli çalışmasını sağlayan bir sistem oluşturarak pazarı ele alacaksak, o zaman planlama da muhtemelen core bir alandır. Aksi takdirde, supporting bir alt domaindir, belki mevcut bazı planlama motorunun üzerine inşa edilmiştir. Aynı mantık laboratuar alt alanına da uygulanabilir: iş vakamızın önemli bir parçası hasta kayıtları ve laboratuvar arasında kusursuz bir entegrasyon ise, o zaman laboratuvar büyük olasılıkla core bir alandır. Aksi takdirde, supporting bir alt alan adıdır.

Sorunlardan Çözümlere

Bazen "problem domain" olarak adlandırılan domaini bulursunuz. Bu, domainin yazılımın çözeceği sorunları tanımlaması gerçeğinden kaynaklanmaktadır (sonuçta, yazılımın ilk etapta yapılmasının bir nedeni vardır). Vaughn Vernon, bir alanı bir problem alanına ve bir çözüm alanına ayırır. Sorun alanı, çözmeye çalıştığımız iş sorunlarına odaklanır. Alt alanlar bu alana aittir.

Çözüm uzayı (solution space), problem uzayındaki (problem space) problemlerin nasıl çözüleceğine odaklanır. Çözüm uzayı daha somut, daha teknik ve daha fazla ayrıntı içerir. Peki sorunlarımızı çözüme nasıl dönüştüreceğiz?

The Ubiquitous Language (Ortak bir dil).

Bir alan adı için yazılım oluşturabilmek için, alanı tanımlamanın bir yoluna ihtiyacınız vardır. İlişkisel bir veri modeline veya benzer bir şeye sahip olmak yeterli değildir. Sadece şeyleri ve onların ilişkilerini değil, aynı zamanda olaylar, süreçler, iş değişmezleri, şeylerin zaman içinde nasıl değiştiği gibi dinamikleri de tanımlayabilmelisiniz. Domain hakkında hem geliştiricilerinizle hem de domain uzmanlarıyla tartışabilmeniz ve mantık yürütebilmeniz gerekir. İhtiyacınız olan şey, ortak bir dildir.

Ortak dil, hem alan uzmanları hem de geliştiriciler tarafından alanı açıklamak ve tartışmak için sürekli olarak kullanılan bir dildir. Kodun kendisinden ayrı olarak, bu dil, Domaine Dayalı Tasarım (DDD)  sürecinin en önemli çıktısıdır. Dilin büyük bir kısmı, alan uzmanları tarafından halihazırda kullanılmakta olan alan terminolojisidir, ancak alan uzmanlarıyla işbirliği içinde yeni kavramlar ve süreçler icat etmeniz de gerekebilir. Bu nedenle, alan uzmanlarının aktif katılımı, Domaine Dayalı Tasarım (DDD)'ın  başarılı olması için kesinlikle gereklidir. Müşteri alanınızı öğretmek ve ortak  bir dil oluşturmanıza yardımcı olmak için zaman ve çaba harcamakla ilgilenmiyorsa, müşteriyi fikrini değiştirmeye ikna etmeye çalışmalı veya başka bir tasarım yöntemi seçmelisiniz.

Ortak dili çeşitli şekillerde belgeleyebilirsiniz. İyi bir başlangıç noktası, bir terimler sözlüğü oluşturmaktır. İş süreçleri, örn. swimline diyagramları ve akış şemaları. UML, farklı şeyler farklı süreçler boyunca ilerlerken durumun nasıl değiştiğini açıklamak için nesneler ve durum diyagramları arasındaki ilişkiyi tanımlamak için kullanılabilir. Alt alan adları da ortak dilin bir parçasıdır ve hatta farklı alt alanlar için dilin farklı "lehçelerini" tanımlamanız gerekebilir. Ortak dilin bu düzenlemesi alan modelidir ve sonunda çalışma koduna dönüştürülecektir. Başka bir deyişle, alan modeli bir veri modeli veya bir UML sınıf diyagramı ile aynı değildir.

Ortak dilin güzel bir özelliği vardır ve bu size doğru yolda olup olmadığınızı söylemesi. Bir iş kavramını veya sürecini dili kullanarak kolayca açıklayabiliyorsanız, doğru yoldasınız demektir. Öte yandan, kendinizi bir şeyi açıklamakta zorlanırken bulursanız, büyük olasılıkla dilden ve dolayısıyla alan modelinizden bir şeyler kaçırıyorsunuzdur. Bu olduğunda, bir alan uzmanı tutmalı ve eksik parçaları aramalısınız. Hatta mevcut modelinizi tamamen tersine çeviren ve daha önce sahip olduğunuzdan çok daha üstün bir domain modeliyle sonuçlanan bir geliştirmeyle karşılaşabilirsiniz.

Introducing Bounded Contexts(Sınırlı Bağlamlara Giriş)

Kusursuz bir dünyada, yeknesak bir dil ve tek bir alanla ilgili her şeyi açıklayacak bir model olurdu. Ne yazık ki, çok küçük ve basit alanlar dışında durum böyle değil. İş süreçleri birbiri içine geçebilir ve hatta çakışabilir. Aynı kelime farklı anlamlara gelebilir veya farklı kelimeler farklı bağlamlarda aynı anlama gelebilir. Nasıl gördüğünüze bağlı olarak, sorun alanında bir sorunu çözmenin birden fazla yolu olabilir (ve genellikle vardır).

Büyük Birleşik Modeli(Big Unified Model) bulmaya çalışmak yerine, gerçekleri kabul etmeyi seçeriz ve bunun yerine sınırlı bağlamlar(bounded context) denen bir şey sunarız. Sınırlı bağlam, yeknesak dilin belirli bir alt kümesinin veya diyalektinin her zaman tutarlı olduğu alanın ayrı bir parçasıdır. Başka bir deyişle, bölme ve yönetme uyguluyor ve domain modelini açıkça tanımlanmış sınırları olan daha küçük, az çok bağımsız modellere ayırıyoruz. Her sınırlı bağlamın kendi adı vardır ve bu ad yeknesak dilin bir parçasıdır.

Sınırlı bağlamlar ve alt alanlar arasında mutlaka bire bir eşleştirme olması gerekmez. Sınırlı bir bağlam çözüm uzayına ve bir alt domain sorun uzayına ait olduğundan, sınırlı bağlamı birçok olası çözüm arasında alternatif bir çözüm olarak düşünmelisiniz. Dolayısıyla, tek bir alt alan, birden çok sınırlı bağlam içerebilir. Kendinizi tek bir sınırlı bağlamın birden çok alt alanı kapsadığı bir durumda da bulabilirsiniz. Buna karşı bir kural yoktur, ancak bu, alt alanlarınızı veya bağlam sınırlarınızı yeniden düşünmeniz gerekebileceğinin bir göstergesidir.

Kişisel olarak, sınırlı bağlamları ayrı sistemler olarak düşünmeyi seviyorum (örneğin, Java dünyasında ayrı çalıştırılabilir JAR'lar veya konuşlandırılabilir WAR'lar). Bunun mükemmel bir gerçek dünya örneği, her mikroservisin kendi sınırlı bağlamı olarak kabul edilebileceği mikroservislerdir. Ancak bu, tüm sınırlı bağlamlarınızı mikroservisler olarak uygulamanız gerektiği anlamına gelmez. Sınırlı bir bağlam, tek bir monolitik sistem içinde ayrı bir alt sistem de olabilir.

Misal

Önceki örnekteki EMR sistemini ve daha spesifik olarak hasta kayıtlarının temel alanını tekrar gözden geçirelim. Orada ne tür sınırlı bağlamlar bulabiliriz? Şimdi sağlık hizmetleri yazılımı konusunda uzman değilim, bu yüzden sadece birkaçını uyduracağım, ama umarım, temel fikri anlarsınız.

Sistem, hem doktor randevuları hem de fizyoterapi için hizmetleri destekler. Ek olarak, yeni hastalar için mülakat yapılan, fotoğraflarının çekildiği ve bir ilk değerlendirmenin verildiği ayrı bir alıştırma süreci vardır. Bu, core domainde aşağıdaki sınırlı bağlamlara yol açar:

1. Hastanın kişisel bilgilerini yönetmek için kişisel bilgiler (Personal Information) (isim, adres, mali bilgiler, tıbbi geçmişi, vb.).
2. Sisteme yeni hastaları tanıtmak için ilk katılım (Onboarding).
3. Doktorların hastayı muayene ederken ve tedavi ederken kullandıkları Tıbbi Muayeneler (Medical Exams).
4. Fizyoterapistlerin hastayı muayene ederken ve tedavi ederken kullandıkları fizyoterapi(Physiotherapy).

Çok basit bir sistemde, muhtemelen her şeyi tek bir bağlama sıkıştırırsınız, ancak bu EMR daha gelişmiştir ve sağlanan her hizmet türü için aerodinamik ve optimize edilmiş özellikler sağlar. Ancak, yine de aynı core alt domainindeyiz.

Bağlamlar Arasındaki İlişkiler

Önemsiz olmayan bir sistemde, çok az (varsa) sınırlı bağlam tamamen bağımsızdır. Çoğu bağlamın diğer bağlamlarla bir tür ilişkisi olacaktır. Bu ilişkilerin belirlenmesi sadece teknik olarak (sistemler teknik olarak nasıl iletişim kuracaklar) değil, aynı zamanda nasıl geliştirildikleri (sistemleri geliştiren ekipler birbirleriyle nasıl iletişim kuracaklar) açısından da önemlidir.

Sınırlı bağlamlar arasındaki ilişkileri belirlemenin en basit yolu, bağlamları yukarı akış bağlamları (upstream contexts) ve aşağı akış bağlamları(downstream contexts) olarak sınıflandırmaktır. Bağlamları bir nehrin yanındaki şehirler olarak düşünün. Akış yukarısındaki şehirlerden akan malzemeler aşağıdaki şehirlere ulaşan nehre bir şeyler döküyor. Malzemelerin bir kısmı aşağı havza şehirleri için çok önemlidir ve bu nedenle nehirden geri alırlar. Diğer şeyler zararlıdır ve aşağı havzadaki şehirlere doğrudan zarar verebilir ("pislik yokuş aşağı yuvarlanır").

Yukarı veya aşağı havza olmanın avantajları ve dezavantajları vardır. Bir yukarı akış bağlamı, herhangi bir yönde gelişmesini bir şekilde özgür kılan başka herhangi bir bağlama bağlı değildir. Bununla birlikte, herhangi bir değişikliğin sonuçları aşağı havza bağlamlarında şiddetli olabilir ve bu da, yukarı akış bağlamında kısıtlamalar getirebilir. Aşağı akış bağlamı, yukarı akış bağlamına bağımlılığıyla sınırlıdır, ancak aşağı akış bağlamının geliştiricilerine bir şekilde yukarı akış bağlamının geliştiricilerine göre daha özgür eller veren diğer bağlamları daha aşağı yönde kırma konusunda endişelenmesine gerek yoktur.

Okların aşağı akış bağlamlarından yukarı akış bağlamlarına işaret ettiği bir bağımlılık diyagramı kullanarak veya U ve D rollerini kullanarak ilişkileri grafiksel olarak tanımlayabilirsiniz.

Son olarak, nerede durduğunuza bağlı olarak bir bağlamın aynı anda hem yukarı akış bağlamı hem de aşağı akış bağlamı olabileceğini unutmayın.

Context Maps and Integration Patterns(Bağlam Haritaları ve Entegrasyon Modelleri)

Bağlamlarımızın ne olduğunu ve nasıl ilişkili olduklarını öğrendikten sonra, bunları nasıl bütünleştireceğimize karar vermeliyiz. Bu birkaç önemli soruyu içerir:

1. Bağlam sınırları nerede?
2. Bağlamlar teknik olarak nasıl iletişim kuracak?
3. Bağlamların domain modelleri arasında nasıl harita oluşturacağız (yani yeknesak bir dilden diğerine nasıl çeviri yapıyoruz)?
4. Yukarı yönde meydana gelen istenmeyen veya sorunlu değişikliklere karşı nasıl korunacağız?
5. Aşağı akış bağlamlarında sorun yaratmaktan nasıl kaçınacağız?

Bu soruların cevapları bir bağlam haritası (context map) halinde derlenecektir. Bağlam haritası şu şekilde grafiksel olarak belgelenebilir:

Bağlam eşlemesini oluşturmayı kolaylaştırmak için, çoğu kullanım durumu için çalışan bir dizi hazır tümleştirme modeli(integration patterns) vardır. Hangi entegrasyon modelini seçtiğinize bağlı olarak, onu gerçekten kullanışlı hale getirmek için bağlam haritasına ek bilgiler eklemeniz gerekebilir.

Partnership(Ortaklık)

Her iki bağlamdaki ekipler işbirliği yapar. Arayüzler - ne olursa olsunlar - her iki bağlamın geliştirme ihtiyaçlarını karşılayacak şekilde gelişir. Birbirine bağlı özellikler, her iki takıma da mümkün olduğunca az zarar verecek şekilde uygun şekilde planlanır ve programlanır.

Shared Kernel (Paylaşılan Çekirdek)

Her iki bağlam da çekirdek olan ortak bir kod tabanını paylaşır. Çekirdek, herhangi bir ekip tarafından değiştirilebilir, ancak önce diğer ekibe danışılmadan yapılamaz. İstenmeyen yan etkilerin ortaya çıkmadığından emin olmak için, sürekli entegrasyon (otomatik test ile) gereklidir. İşleri olabildiğince basit tutmak için, paylaşılan çekirdek mümkün olduğu kadar küçük tutulmalıdır. Paylaşılan çekirdekte çok sayıda model kodu varsa, bu bağlamların aslında tek bir büyük bağlamda birleştirilmesi gerektiğinin bir işareti olabilir.

Customer-Supplier (Müşteri - Satıcı)

Bağlamlar, yukarı akış-aşağı akış ilişkisi içindedir ve bu ilişki, yukarı akış ekibi tedarikçi ve aşağı akış ekibi müşteri olacak şekilde biçimlendirilir. Bu nedenle, her iki takım da kendi sistemleri üzerinde az çok bağımsız olarak çalışabilse de, yukarı akış ekibinin (tedarikçi) aşağı akış ekibinin (müşteri) ihtiyaçlarını hesaba katması gerekir.

Conformist (Uyumlu Kimse)

Bağlamlar yukarı akış-aşağı akış ilişkisi içindedir. Bununla birlikte, yukarı akış ekibinin, aşağı akış ekibinin ihtiyaçlarını karşılamak için hiçbir motivasyonu yoktur (örneğin, daha büyük bir tedarikçiden bir hizmet olarak sipariş edilebilir). Alt ekip, her ne olursa olsun, üst ekip modeline uymaya karar verir.

Anticorruption Layer (Adaptosyon Katmanı)

Bağlamlar yukarı akış-aşağı akış ilişkisi içindedir ve yukarı akış ekibi, aşağı akış ekibinin ihtiyaçlarını umursamaz. Ancak, yukarı akış modeline uymak yerine, aşağı akış ekibi, aşağı akış bağlamını yukarı akış bağlamındaki değişikliklerden koruyan bir soyutlama katmanı oluşturmaya karar verir. Bu adaptasyon katmanı, aşağı akış ekibinin ihtiyaçlarına en çok uyan bir domain modeliyle çalışmasına olanak tanır ve yine de yukarı akış bağlamıyla bütünleşir. Yukarı akış bağlamı değiştiğinde, adaptasyon katmanının da değişmesi gerekir, ancak aşağı akış bağlamının geri kalanı değişmeden kalabilir. Bu stratejiyi, yukarı akış arayüzündeki değişiklikleri tespit etmek için otomatik testlerin kullanıldığı sürekli entegrasyonla birleştirmek iyi bir fikir olabilir.

Open Host Service

Bir sisteme erişim, açıkça tanımlanmış bir protokol kullanılarak, açıkça tanımlanmış hizmetler tarafından sağlanır. Protokol, ihtiyaç duyan herkesin sisteme entegre olabilmesi için açıktır. Web hizmetleri ve mikroservisler, bu entegrasyon modelinin güzel bir örneğidir. Bu örüntü, bağlamlar ve onları geliştiren takımlar arasındaki ilişkiyi önemsemediği için diğerlerinden farklıdır. open host service modelini diğer modellerden herhangi biriyle birleştirebilirsiniz.

Bu kalıbı kullanırken dikkat edilmesi gereken nokta, protokolü basit ve kararlı tutmaktır. Sistem istemcilerinin çoğu bu protokolden ihtiyaç duyduklarını alabilmelidir. Kalan özel durumlar için özel entegrasyon noktaları oluşturun.

Published Language (Yayın Dili)

Bu, şahsen açıklamakta en zorlandığım entegrasyon modeli. Benim baktığım şekilde, yayınlanan dil, open host servisine en yakın olanıdır ve genellikle bu entegrasyon modeliyle birlikte kullanılır. Sistemin girişi ve çıkışı için belgelenmiş bir dil (örneğin XML tabanlı) kullanılır. Yayınlanan dile uyduğunuz sürece belirli bir kitaplığı veya bir şartnamenin belirli bir uygulamasını kullanmaya gerek yoktur. Yayınlanmış dillerin gerçek dünya örnekleri, matematiksel formülleri temsil eden MathML ve coğrafi bilgi sistemlerinde coğrafi özellikleri temsil eden GML'dir.

Lütfen web hizmetlerini yayınlanan bir dille birlikte kullanmanız gerekmediğini unutmayın. Ayrıca bir dosyanın bir dizine bırakıldığı ve çıktıyı başka bir dosyada depolayan bir toplu iş tarafından işlendiği bir kuruluma sahip olabilirsiniz.

Separate Ways (Ayrı Roller)

Bu entegrasyon modeli, herhangi bir entegrasyon gerçekleştirmemesi açısından özeldir. Yine de, alet çantasında tutulması gereken önemli bir kalıptır ve çok fazla para ve zaman tasarrufu sağlayabilir. İki bağlam arasındaki entegrasyonun yararı artık çabaya değmediğinde, bağlamları birbirinden ayırmak ve bağımsız olarak evrimleşmelerine izin vermek daha iyidir. Bunun nedeni, sistemlerin artık birbirleriyle ilişkili olmadıkları bir noktaya evrilmiş olmaları olabilir. Aşağı akış bağlamının fiilen kullandığı yukarı akış bağlamı tarafından sağlanan (birkaç) hizmet, aşağı akış bağlamında yeniden uygulanır.

Stratejik Domaine Dayalı Tasarım Neden Önemlidir?

Stratejik domaine dayalı tasarımın aslında daha büyük projeler için tasarlandığına inanıyorum, ancak projede DDD'nin başka herhangi bir parçasını kullanmasanız bile, bundan daha küçük projelerde de yararlanabileceğinizi düşünüyorum.

Şahsen benim için stratejik domaine dayalı tasarımın başlıca çıkarımları şunlardır:

1. Sınırlar getirir. Kapsam sünmesi (Scope creep), tüm hobi projelerimde değişmeyen bir faktördür. Sonunda, üzerinde çalışmak eğlenceden daha kapsamlı hale gelir veya tek başına bitirmek tamamen gerçekçi olmaz. Müşteri projeleri üzerinde çalışırken, bir şeyleri aşırı düşünerek veya aşırı mühendislik yaparak teknik kapsamın sünmesine neden olmamak için çok çalışmam gerekir. Sınırlar - nerede olurlarsa olsunlar - projeyi daha küçük parçalara bölmeme ve doğru zamanda doğru olanlara odaklanmama yardımcı oluyor.
2. Her durumda çalışan bir süper model bulmamı gerektirmiyor. Stratejik DDD gerçek dünyada, genellikle az çok açıkça tanımlanmış bağlamlarda birçok küçük modelin olduğunu kabul eder. Bu modelleri kırmak yerine kucaklar.
3. Sisteminizin getireceği değeri ve en büyük değeri elde etmek için çabalarınızın çoğunu nereye koymanız gerektiğini düşünmenize yardımcı olur. Doğru bir şekilde tanımlamanın ve ardından core domaine odaklanmanın büyük bir fark yaratacağı projelerden kişisel deneyime sahibim. Ne yazık ki, stratejik DDD'yi henüz duymamıştım ve hem zaman hem de para israf ettim.

Ayrıca, bu yaklaşımla riskleri tanımlayacak kadar iyi olduğumu da biliyorum: alt alanlar ve sınırlı bağlamlar bulmak adına alt alanlar ve sınırlı bağlamlar bulmak. Sevdiğim yeni bir şey öğrendiğimde, onu gerçek dünyada denemeyi çok isterim. Bu bazen orada olmayan şeyleri aramaya gittiğim anlamına gelebilir. Buradaki önerim, her zaman bir core domain ve bir sınırlı bağlam (bounded context) ile başlamaktır. Domain modellemesini dikkatlice yapıyorum, ek alt domainleri ve sınırlı bağlamlar varsa, sonunda kendilerini ortaya cıkaracaklardır.

Çeviri için izin veren  Petter Holmström'e teşekkürler.

Bonus :

Barış Velioğlu

Domain Driven Design Kimdir?

https://barisvelioglu61.medium.com/domain-driven-design-kimdir-fe658cb0f6f0

Softtech 2020 Teknoloji Raporu

 Softtech 2020 Teknoloji Raporu, 2020 yılında teknolojik yenilikleri detaylı halde raporlayan güzel bir çalışma olmuş. 

Bahsedilen rapora buradan ulaşabilirsiniz.

NoSQL - İlişkisel Veritabanları (RDMS) Karşılaştırması - mongodb.com çevirisi

Merhaba bu yazımda size mongodb.com'da yayınlanan NoSQL vs Relational Databases başlıklı makaleyi çevireceğim.

Yazının orjinali,

NoSQL  - İlişkisel Veritabanları (RDMS) Karşılaştırması

Aralarından seçim yapabileceğiniz iki ana modern veritabanı türü ilişkisel ve ilişkisel olmayan , SQL veya NoSQL (sorgu dilleri için) olarak da bilinen veritabanlarıdır. Hangi veritabanının ihtiyaçlarınıza en uygun olduğuna karar verirken aşina olmanız gereken birkaç temel farklılık vardır.

TLDR: NoSQL (“SQL olmayan” veya “sadece SQL” değil) veritabanları, ölçeklendirme, hızlı sorgular, sık uygulama değişikliklerine izin verilmesi ve programcıları geliştiriciler için basitleştirmeye odaklanarak 2000'li yılların sonlarında geliştirilmiştir. SQL (Yapılandırılmış Sorgu Dili) ile erişilen ilişkisel veritabanları, depolama alanı geliştirici süresinden çok daha maliyetli olduğundan veri tekrarını azaltmaya odaklanarak 1970'lerde geliştirilmiştir. SQL veritabanları katı, karmaşık, tablo şeklinde şemalara sahip olma eğilimindedir ve tipik olarak pahalı dikey ölçeklendirme gerektirir.

tldr özeti: SQL veritabanları ilişkisel veritabanları olarak bilinir ve kesin, önceden tanımlanmış bir şema gerektiren tablo tabanlı bir veri yapısına sahiptir. NoSQL veritabanları veya ilişkisel olmayan veritabanları belge tabanlı, grafik veritabanları, anahtar / değer çiftleri veya geniş sütun depoları olabilir. NoSQL veritabanları, önceden yapılandırılmamış bir şema gerektirmez ve "yapılandırılmamış veriler" ile daha serbest çalışmanıza olanak tanır. İlişkisel veritabanları dikey olarak ölçeklendirilebilir, ancak genellikle daha pahalıdır, oysa NoSQL veritabanlarının yatay ölçekleme özelliği daha düşük maliyetlidir.

İlişkisel Veritabanlarının (RDBMS) ve NoSQL'in Tarihçesi

İlişkisel veritabanları (RDBMS) 40 yılı aşkın bir süredir kullanılmaktadır. Tarihsel olarak, veri yapılarının çok daha basit ve statik olduğu zamanlarda iyi çalıştılar. Bununla birlikte, teknoloji ve büyük veri uygulamaları ilerledikçe, geleneksel SQL tabanlı ilişkisel veritabanı hızla genişleyen veri hacimlerini ve veri yapılarının artan karmaşıklıklarını ele almak için daha az donanımlıydı. Son on yılda, ilişkisel olmayan, NoSQL veritabanları geleneksel SQL tabanlı ilişkisel veritabanlarına daha esnek, ölçeklenebilir, düşük maliyetli bir alternatif sunmak için daha popüler hale geldi.

1-Veri Modelleri ve Şema

NoSQL veritabanları dinamik şema içerir ve “yapılandırılmamış veriler” olarak bilinenleri kullanmanızı sağlar. Bu, ilk önce şemayı tanımlamak zorunda kalmadan uygulamanızı oluşturabileceğiniz anlamına gelir. İlişkisel bir veritabanında, veritabanına veri eklemeden önce şemanızı tanımlamanız gerekir. Önceden tanımlanmış bir şemaya ihtiyaç duyulmaması, veri ve gereksinimler değiştikçe NoSQL veritabanlarının güncellenmesini çok daha kolay hale getirir. İlişkisel bir veritabanında şema yapısının değiştirilmesi son derece pahalı, zaman alıcı olabilir ve genellikle kesinti veya hizmet kesintilerini içerebilir.

2-Veri yapısı

İlişkisel veritabanları tablo tabanlıdır. NoSQL veritabanları belge tabanlı, grafik veritabanları, anahtar / değer çiftleri veya geniş sütun depoları olabilir. İlişkisel veritabanları, verilerin çoğunlukla yapılandırıldığı ve ilişkileri tarafından açıkça tanımlandığı bir dönemde oluşturulmuştur. Bugün, bugünkü verilerin çok daha karmaşık olduğunu biliyoruz. NoSQL veritabanları, günümüzde var olan verilerin çoğunu oluşturan daha karmaşık, yapılandırılmamış verileri (metinler, sosyal medya gönderileri, fotoğraflar, videolar, e-posta gibi) işleyecek şekilde tasarlanmıştır.

3-Ölçekleme

İlişkisel veritabanları dikey olarak ölçeklenebilir ancak genellikle pahalıdır. Tüm veritabanını barındırmak için tek bir sunucuya ihtiyaç duyduklarından, ölçeklendirmek için daha büyük ve daha pahalı bir sunucu satın almanız gerekir. NoSQL veritabanını ölçeklendirmek, ilişkisel veritabanına göre çok daha ucuzdur, çünkü ucuz, ticari sunucular üzerinde yatay olarak ölçekleyerek kapasite ekleyebilirsiniz.

4-Geliştirme Modeli

NoSQL veritabanları daha çok açık kaynak topluluğunun bir parçası olma eğilimindedir. İlişkisel veritabanları, yazılımlarının kullanımı için kullanılan lisanslama ücretleri ile tipik olarak kapalı bir kaynaktır.

Genel NoSQL ve İlişkisel Veritabanı (diğer adıyla SQL) Soruları

NoSQL SQL'den daha mı iyi?

-NoSQL, daha karmaşık, sürekli değişen veri setlerine sahip ve hemen tanımlanması gerekmeyen esnek bir veri modeli gerektiren modern uygulamalar için daha iyi bir seçenek olma eğilimindedir. NoSQL veritabanlarını tercih eden çoğu geliştirici veya kuruluş, pazara daha hızlı gitmelerini, güncellemeleri daha hızlı hale getirmelerini sağlayan çevik özelliklere ilgi duyuyor. Geleneksel, SQL tabanlı, ilişkisel veritabanlarının aksine, NoSQL veritabanları verileri gerçek zamanlı olarak depolayabilir ve işleyebilir.

-SQL veritabanlarının hala bazı özel kullanım durumları olmasına rağmen, NoSQL veritabanlarının SQL veritabanlarının muazzam maliyetler ve hız, çeviklik vb. Kritik fedakarlıkları olmadan işleyemediği birçok özelliği vardır.

SQL ve NoSQL arasındaki farklar

1-Veri Depolama Modeli : 

SQL Veritabanları : Sabit satır ve sütun içeren tablolar

NoSQL Veritabanları : Document: JSON belgeleri, Anahtar / değer: anahtar / değer çiftleri, Geniş sütun: satır ve dinamik sütun içeren tablolar, Grafik: nodes ve edges.

2-Gelişim Tarihi :

SQL Veritabanları : 1970'lerde veri tekrarını azaltmaya odaklanarak geliştirildi

NoSQL Veritabanları : 2000'li yılların sonlarında, çevik ve DevOps uygulamaları tarafından ölçeklendirmeye ve hızlı uygulama değişikliğine izin vererek geliştirildi.

3-Örnekler:

SQL Veritabanları : Oracle, MySQL, Microsoft SQL Server ve PostgreSQL

NoSQL Veritabanları :  Belge: MongoDB ve CouchDB, Anahtar / değer çifti: Redis ve DynamoDB, Geniş sütun: Cassandra ve HBase, Grafik: Neo4j ve Amazon Neptün

4-Birincil Amaç:

SQL Veritabanları : Genel amaç

NoSQL Veritabanları : Document(Belge): genel amaçlı, Key/Value(Anahtar / değer): basit arama sorgularıyla büyük miktarlarda veri, Wide-column(Geniş sütun): tahmin edilebilir sorgu desenleriyle büyük miktarlarda veri, Graph(Grafik): bağlı veriler arasındaki ilişkileri analiz etme ve çaprazlama

5-Şemalar :

SQL Veritabanları : Katı

NoSQL Veritabanları : Esnek

6-Ölçekleme :

SQL Veritabanları : Dikey (daha büyük bir sunucu ile ölçeklendirme)

NoSQL Veritabanları :  Yatay (emtia sunucularında genişleme)

7-Çok Kayıtlı ACID İşlemleri :

SQL Veritabanları : Destekler

NoSQL Veritabanları : Çoğu çoklu kayıt ACID işlemlerini desteklemez. Ancak, bazıları - MongoDB gibi - destekler.

8-Joins :

SQL Veritabanları : Genellikle gerekli

NoSQL Veritabanları : Genellikle gerekli değildir

9- Verileri Nesne ile Eşleme :

SQL Veritabanları : ORM (nesne-ilişkisel eşleme) gerektirir

NoSQL Veritabanları :  Birçoğu ORM gerektirmez. MongoDB belgeleri, en popüler programlama dillerindeki veri yapılarıyla doğrudan eşleşir.

NoSQL Veritabanlarının Faydaları Nelerdir?

NoSQL veritabanları ilişkisel veritabanlarına göre birçok fayda sağlar. NoSQL veritabanlarının esnek veri modelleri vardır, yatay olarak ölçeklendirilir, inanılmaz derecede hızlı sorguları vardır ve geliştiricilerin birlikte çalışması kolaydır.

-Esnek veri modelleri

NoSQL veritabanları genellikle çok esnek şemalara sahiptir. Esnek bir şema, gereksinimler değiştikçe veritabanınızda kolayca değişiklik yapmanızı sağlar. Kullanıcılarınıza daha hızlı değer katmak için yeni uygulama özelliklerini hızlı bir şekilde ve sürekli olarak entegre edebilirsiniz.

-Yatay ölçeklendirme

Çoğu SQL veritabanı, geçerli sunucunuzun kapasite gereksinimlerini aştığınızda dikey olarak ölçeklendirmenizi (daha büyük, daha pahalı bir sunucuya geçmenizi) gerektirir. Tersine, çoğu NoSQL veritabanı yatay olarak ölçeklendirmenize izin verir, yani ihtiyacınız olduğunda daha ucuz, emtia sunucuları ekleyebilirsiniz.

-Hızlı sorgular

NoSQL veritabanlarındaki sorgular SQL veritabanlarından daha hızlı olabilir. Neden? SQL veritabanlarındaki veriler genellikle normalleştirilir, bu nedenle tek bir nesne veya varlık için sorgular birden çok tablodaki verilere katılmanızı gerektirir. Tablolarınız büyüdükçe birleşimler pahalı hale gelebilir. Ancak, NoSQL veritabanlarındaki veriler genellikle sorgular için optimize edilmiş bir şekilde saklanır. MongoDB'yi kullandığınızda temel kural Veri'dir, birlikte erişildiğinde birlikte depolanmalıdır. Sorgular genellikle join  gerektirmez, bu nedenle sorgular çok hızlıdır.

-Easy for developers

MongoDB gibi bazı NoSQL veritabanları veri yapılarını popüler programlama dillerinin veri haritalarıyla eşler. Bu eşleme, geliştiricilerin verilerini uygulama kodlarında kullandıkları gibi depolamasına olanak tanır. Bu önemsiz bir avantaj gibi görünse de, bu eşleme geliştiricilerin daha az kod yazmalarına olanak tanıyarak daha hızlı geliştirme süresi ve daha az hataya yol açabilir.

NoSQL Veritabanlarının Dezavantajları Nelerdir?

NoSQL veritabanlarının en sık belirtilen dezavantajlarından biri, birden fazla belge üzerinde ACID (atomisite, tutarlılık, izolasyon, dayanıklılık) işlemlerini desteklememesidir. Uygun şema tasarımı ile, birçok uygulama için tek kayıt atomisitesi kabul edilebilir. 

Bununla birlikte, birden fazla kayıtta ACID gerektiren hala birçok uygulama vardır.Bu kullanım durumlarını ele almak için MongoDB, 4.0 sürümünde çok belgeli ACID işlemleri için destek ekledi ve bunları parçalanmış kümeleri kapsayacak şekilde 4.2'de genişletti.

NoSQL veritabanlarındaki veri modelleri veri tekrarnını azaltmak için değil, genellikle sorgular için optimize edildiğinden, NoSQL veritabanları SQL veritabanlarından daha büyük olabilir. Depolama şu anda o kadar ucuz ki çoğu bunu küçük bir dezavantaj olarak görülür ve bazı NoSQL veritabanları da depolama ayak izini azaltmak için sıkıştırmayı destekliyor.

Seçtiğiniz NoSQL veritabanı türüne bağlı olarak, tüm kullanım durumlarınızı tek bir veritabanında gerçekleştiremeyebilirsiniz. Örneğin, grafik veritabanları verilerinizdeki ilişkileri analiz etmek için mükemmeldir, ancak aralık sorguları gibi verilerin günlük olarak alınması için ihtiyacınız olanları sağlamayabilir. Bir NoSQL veritabanı seçerken, kullanım durumlarınızın ne olacağını ve MongoDB gibi genel amaçlı bir veritabanının daha iyi bir seçenek olup olmadığını düşünün.