İşletme gereksinimleri için oluşturunBuild for the needs of the business

Her tasarım kararının iş gereksinimleri açısından haklı bir gerekçesi olmalıdırEvery design decision must be justified by a business requirement

Bu tasarım ilkesi belirgin görünebilir, ancak bir çözüm tasarlarken göz önünde bulundurmanız önemlidir.This design principle may seem obvious, but it's crucial to keep in mind when designing a solution. Milyonlarca mı yoksa birkaç bin kullanıcınız mı olacak?Do you anticipate millions of users, or a few thousand? Bir saatlik uygulama kesintisi kabul edilebilir mi?Is a one hour application outage acceptable? Trafikte büyük iş yükü artışları mı, yoksa öngörülebilir bir iş yükü mü bekliyorsunuz?Do you expect large bursts in traffic, or a very predictable workload? Sonuçta her tasarım kararının iş gereksinimleri açısından haklı bir gerekçesi olmalıdır.Ultimately, every design decision must be justified by a business requirement.

ÖnerilerRecommendations

Kurtarma süresi hedefi (RTO), kurtarma noktası hedefi (RPO) ve en fazla kesinti toleransı (MTO) dahil olmak üzere iş hedeflerini belirleyin.Define business objectives, including the recovery time objective (RTO), recovery point objective (RPO), and maximum tolerable outage (MTO). Bu sayılar mimari hakkında kararlarda dikkate alınmalıdır.These numbers should inform decisions about the architecture. Örneğin, düşük RTO elde etmek için ikincil bir bölgeye otomatik yük devretme uygulayabilirsiniz.For example, to achieve a low RTO, you might implement automated failover to a secondary region. Ancak çözümünüz daha yüksek bir RTO toleransına sahipse bu artıklık düzeyi gereksiz olabilir.But if your solution can tolerate a higher RTO, that degree of redundancy might be unnecessary.

Kullanılabilirlik ve performans ölçümleri dahil olmak üzere hizmet düzeyi sözleşmelerini (SLA) ve hizmet düzeyi hedeflerini (SLO) belgeleyin.Document service level agreements (SLA) and service level objectives (SLO), including availability and performance metrics. %99,95 kullanılabilirlik sunan bir çözüm oluşturabilirsiniz.You might build a solution that delivers 99.95% availability. Bu yeterli midir?Is that enough? Yanıt bir iş kararıdır.The answer is a business decision.

Uygulamayı iş çerçevesinde modelleyin.Model the application around the business domain. İş gereksinimlerini çözümleyerek başlayın.Start by analyzing the business requirements. Uygulamanın modelini oluşturmak için bu gereksinimleri kullanın.Use these requirements to model the application. İş süreçlerine ve kullanım senaryolarına uygun etki alanı modelleri oluşturmak için etki alanı odaklı tasarım (DDD) yaklaşımı kullanmayı değerlendirin.Consider using a domain-driven design (DDD) approach to create domain models that reflect the business processes and use cases.

Hem işlevsel, hem de işlevsel olmayan gereksinimleri belirleyin.Capture both functional and nonfunctional requirements. İşlevsel gereksinimler, uygulamanın doğru şeyi yapıp yapmadığını değerlendirmeye olanak tanır.Functional requirements let you judge whether the application does the right thing. İşlevsel olmayan gereksinimler, uygulamanın bu şeyleri iyi yapıp yapmadığını değerlendirmeyi sağlar.Nonfunctional requirements let you judge whether the application does those things well. Özellikle, ölçeklenebilirlik, kullanılabilirlik ve gecikme süresi için gereksinimlerinizi anladığınızdan emin olun.In particular, make sure that you understand your requirements for scalability, availability, and latency. Bu gereksinimler tasarım kararlarını ve teknoloji seçimini etkiler.These requirements will influence design decisions and choice of technology.

İş yüküne göre parçalara ayırın.Decompose by workload. Burada kullanıldığı şekliyle "iş yükü" terimi, diğer görevlerden mantıksal olarak ayrılabilen, ayrık bir özellik veya bilgi işlem görevi anlamına gelmektedir.The term "workload" in this context means a discrete capability or computing task, which can be logically separated from other tasks. Farklı iş yüklerinin kullanılabilirlik, ölçeklenebilirlik, veri tutarlılığı ve olağanüstü durum kurtarma konularında farklı gereksinimleri olabilir.Different workloads may have different requirements for availability, scalability, data consistency, and disaster recovery.

Büyümeyi planlayın.Plan for growth. Bir çözüm kullanıcı sayısı, işlem hacmi, veri depolama ve benzeri konularda geçerli gereksinimlerinizi karşılayabilir.A solution might meet your current needs, in terms of number of users, volume of transactions, data storage, and so forth. Ancak, sağlam bir uygulama, büyük mimari değişiklikler olmadan büyümeye olanak verir.However, a robust application can handle growth without major architectural changes. Bkz. Ölçeğin genişletilebileceği şekilde tasarlama ve Bölümleyerek sınırları aşma.See Design to scale out and Partition around limits. Ayrıca iş modelinizin ve iş gereksinimlerinizin büyük olasılıkla zamanla değişeceğini göz önünde bulundurun.Also consider that your business model and business requirements will likely change over time. Bir uygulamanın hizmet modeli ve veri modelleri sabitse, yeni kullanım örnekleri ve senaryoları için uygulamayı geliştirmek zorlaşır.If an application's service model and data models are too rigid, it becomes hard to evolve the application for new use cases and scenarios. Bkz. Gelişmeye açık olarak tasarlama.See Design for evolution.

Maliyetleri yönetme.Manage costs. Geleneksel şirket içi uygulamada donanım için önceden ücret ödersiniz (CAPEX).In a traditional on-premises application, you pay upfront for hardware (CAPEX). Bir bulut uygulamasında tükettiğiniz kaynaklar için ödeme yaparsınız.In a cloud application, you pay for the resources that you consume. Tükettiğiniz hizmetler için kullanılan fiyatlandırma modeli anladığınızdan emin olun.Make sure that you understand the pricing model for the services that you consume. Toplam maliyet, ağ bant genişliği kullanımını, depolama, IP adresleri, hizmet tüketimi ve diğer etkenleri içerecektir.The total cost will include network bandwidth usage, storage, IP addresses, service consumption, and other factors. Daha fazla bilgi için bkz. Azure fiyatlandırma.See Azure pricing for more information. Ayrıca işlem maliyetlerinizi göz önünde bulundurun.Also consider your operations costs. Bulutta, donanım veya diğer altyapıları yönetmeniz gerekmez, ancak hala DevOps, olay yanıtlama, olağanüstü durum kurtarma ve benzerleri de dahil olmak üzere uygulamalarınızı yönetmeniz gerekir.In the cloud, you don't have to manage the hardware or other infrastructure, but you still need to manage your applications, including DevOps, incident response, disaster recovery, and so forth.