Mikro hizmetler tasarlama: Etki alanı analiziDesigning microservices: Domain analysis

En büyük güçlük mikro Hizmetleri tek tek sınırları tanımlamaktır.One of the biggest challenges of microservices is to define the boundaries of individual services. Genel Hizmet "bir şey" yapmalısınız kuralıdır — ancak bu kural uygulamaya koymak dikkatli düşünce gerektirir.The general rule is that a service should do "one thing" — but putting that rule into practice requires careful thought. "Doğru" tasarım oluşturacak mekanik işlem yoktur.There is no mechanical process that will produce the "right" design. İç iş etki alanı, gereksinimleri ve hedefleri hakkında düşünmek zorunda.You have to think deeply about your business domain, requirements, and goals. Aksi takdirde, sıkı eşlenmesiyle veya arabirimleri kötü tasarlanmış hizmetler arasında gizli bağımlılıklar gibi istenmeyen bazı özellikleri sergiler sayfalarınızla bir tasarım kalabilirsiniz.Otherwise, you can end up with a haphazard design that exhibits some undesirable characteristics, such as hidden dependencies between services, tight coupling, or poorly designed interfaces. Bu bölümde, biz mikro hizmetler tasarlama için etki alanı odaklı bir yaklaşım uygular.In this chapter, we take a domain-driven approach to designing microservices.

Mikro hizmetler, iş becerileriniz, veri erişimi veya Mesajlaşma gibi değil yatay Katmanlar çevresinde tasarlanmalıdır.Microservices should be designed around business capabilities, not horizontal layers such as data access or messaging. Ayrıca, bunlar gevşek eşleştirme ve yüksek işlevsel Uyuma sahip olmalıdır.In addition, they should have loose coupling and high functional cohesion. Mikro hizmetler olan gevşek , bir hizmetin diğer hizmetlerin aynı anda güncelleştirilmesine gerek kalmadan değiştirebilirsiniz.Microservices are loosely coupled if you can change one service without requiring other services to be updated at the same time. Bir mikro hizmetidir cohesive kullanıcı hesaplarını yönetme veya teslim geçmiş izleme gibi iyi tanımlanmış, tek amaçlı olup olmadığını.A microservice is cohesive if it has a single, well-defined purpose, such as managing user accounts or tracking delivery history. Bir hizmeti, etki alanı bilgisini kapsülleyin ve istemcilerden gelen bilgilerden soyut.A service should encapsulate domain knowledge and abstract that knowledge from clients. Örneğin, bir istemci bir insansız hava aracı ile zamanlama algoritma veya insansız hava aracı ile fleet nasıl yönetilir ayrıntılarını bilmeden zamanlanabilmesi.For example, a client should be able to schedule a drone without knowing the details of the scheduling algorithm or how the drone fleet is managed.

Etki alanı Odaklı Tasarım (DDD) çoğu alabileceği bir çerçeve sağlar, iyi tasarlanmış bir mikro hizmetler kümesi yolu.Domain-driven design (DDD) provides a framework that can get you most of the way to a set of well-designed microservices. DDD iki farklı stratejik ve taktiksel aşamadan oluşur.DDD has two distinct phases, strategic and tactical. Stratejik DDD büyük ölçekli sistem yapısını tanımlarsınız.In strategic DDD, you are defining the large-scale structure of the system. Stratejik DDD Mimarinizi iş özelliklerine odaklanan kalmasını sağlamaya yardımcı olur.Strategic DDD helps to ensure that your architecture remains focused on business capabilities. Taktiksel DDD, etki alanı modeli oluşturmak için kullanabileceğiniz tasarım desenleri sunmaktadır.Tactical DDD provides a set of design patterns that you can use to create the domain model. Bu düzenleri, varlıklar, toplamlar ve etki alanı hizmetleri içerir.These patterns include entities, aggregates, and domain services. Bu Taktik desenleri ve her ikisi de gevşek biçimde eşleşmiş cohesive mikro hizmetler tasarlama yardımcı olur.These tactical patterns will help you to design microservices that are both loosely coupled and cohesive.

Bir etki alanı Odaklı Tasarım (DDD) işlem diyagramı

Bu bölümde ve sonraki, biz bunları insansız hava aracı ile teslimat uygulaması için uygulama aşağıdaki adımlarda yardımcı olacağız:In this chapter and the next, we'll walk through the following steps, applying them to the Drone Delivery application:

  1. Uygulamanın işlevsel gereksinimlerini anlamak için iş etki alanı çözümleyerek başlayın.Start by analyzing the business domain to understand the application's functional requirements. Bu adımın çıkış, bir etki alanı modellerini daha resmi kümesi olarak iyileştirilmektedir etki alanının resmi olmayan bir açıklamasıdır.The output of this step is an informal description of the domain, which can be refined into a more formal set of domain models.

  2. Ardından, tanımlama sınırlanmış Bağlamlar etki alanının.Next, define the bounded contexts of the domain. Her bir sınırlanmış bağlam daha büyük bir uygulamanın belirli bir alt etki alanı temsil eden bir etki alanı modeli içerir.Each bounded context contains a domain model that represents a particular subdomain of the larger application.

  3. İçinde bir sınırlanmış bağlam, taktiksel DDD deseni varlıklar, toplamlar ve etki alanı hizmetleri tanımlamak için geçerlidir.Within a bounded context, apply tactical DDD patterns to define entities, aggregates, and domain services.

  4. Önceki adımdan gelen sonuçları, mikro hizmetler, uygulamanızda tanımlamak için kullanın.Use the results from the previous step to identify the microservices in your application.

Bu bölümde, biz öncelikle DDD ile ilgilenir ilk üç adımı kapsar.In this chapter, we cover the first three steps, which are primarily concerned with DDD. Sonraki bölümde, biz mikro Hizmetleri belirleyin.In the next chapter, we will identify the microservices. Ancak, DDD yinelemeli, devam eden bir işlem olduğunu unutmamak önemlidir.However, it's important to remember that DDD is an iterative, ongoing process. Hizmet sınırları içinde taş sabit değildir.Service boundaries aren't fixed in stone. Bir uygulama geliştikçe hizmet birkaç küçük hizmetlere bölmek karar verebilirsiniz.As an application evolves, you may decide to break apart a service into several smaller services.

Not

Bu bölümde, bir tam ve kapsamlı bir etki alanı analizi göstermek için tasarlanmamıştır.This chapter is not meant to show a complete and comprehensive domain analysis. Biz kasıtlı olarak örnek önemli noktalarını göstermek için kısa tutulur.We deliberately kept the example brief, in order to illustrate the main points. Eric Evans öneririz DDD daha fazla arka plan için etki alanı Odaklı Tasarım, ilk terimi sunulan rehberi.For more background on DDD, we recommend Eric Evans' Domain-Driven Design, the book that first introduced the term. Başka bir iyi başvuru Implementing Domain-Driven tasarım Vaughn Vernon tarafından.Another good reference is Implementing Domain-Driven Design by Vaughn Vernon.

Etki çözümlemeAnalyze the domain

DDD yaklaşımı kullanarak, böylece her hizmetin işlevsel iş gereksinimleri için uygun bir kullanımdır forms mikro hizmetler tasarlamak için yardımcı olur.Using a DDD approach will help you to design microservices so that every service forms a natural fit to a functional business requirement. Teknoloji Seçimleri tasarımınızı dikte ya da kuruluş sınırları izin vererek yakalama önlemenize yardımcı olabilir.It can help you to avoid the trap of letting organizational boundaries or technology choices dictate your design.

Herhangi bir kod yazmadan önce bir Kuşbakışı görünümünü oluşturmakta olduğunuz sistem gerekir.Before writing any code, you need a bird's eye view of the system that you are creating. DDD başlar iş etki alanı modelleme ve oluşturma bir etki alanı modeli.DDD starts by modeling the business domain and creating a domain model. Etki alanı modeli, iş etki alanının soyut bir modeldir.The domain model is an abstract model of the business domain. Oluşturur ve etki alanı bilgisini düzenler ve ortak dil, geliştiricilere ve etki alanı uzmanları sağlar.It distills and organizes domain knowledge, and provides a common language for developers and domain experts.

Tüm iş işlevleri ve kendi bağlantılarını eşleyerek başlatın.Start by mapping all of the business functions and their connections. Bu, büyük olasılıkla, etki alanı uzmanları, yazılım mimarları ve diğer proje katılımcıları içeren çabaya olacaktır.This will likely be a collaborative effort that involves domain experts, software architects, and other stakeholders. Herhangi belirli formalism kullanmanız gerekmez.You don't need to use any particular formalism. Bir diyagramını taslak veya Beyaz Tahta üzerinde çizin.Sketch a diagram or draw on whiteboard.

Diyagramda doldururken ayrı bir alt etki alanlarını tanımlamak başlatılabilir.As you fill in the diagram, you may start to identify discrete subdomains. Hangi işlevleri yakından ilişkilidir?Which functions are closely related? İş için çekirdek işlevlerdir ve bulunabilecek hizmetleri sağlayan?Which functions are core to the business, and which provide ancillary services? Bağımlılık grafiği nedir?What is the dependency graph? Bu ilk aşamada teknolojileri veya uygulama ayrıntıları ile ilgili değildir.During this initial phase, you aren't concerned with technologies or implementation details. Bu, işleme ve faturalandırma sistemleri ödeme CRM gibi dış sistemlerle tümleştirmek için uygulamanın nerede gerekir yerde unutmamalısınız belirtti.That said, you should note the place where the application will need to integrate with external systems, such as CRM, payment processing, or billing systems.

İnsansız hava aracı ile teslimat: İş analiz etmeDrone Delivery: Analyzing the business domain

Bazı ilk etki alanı çözümleme sonrasında, Fabrikam ekibi insansız hava aracı ile teslimat etki alanını gösteren bir kaba taslak ile birlikte gelen.After some initial domain analysis, the Fabrikam team came up with a rough sketch that depicts the Drone Delivery domain.

İnsansız hava aracı ile teslimat etki alanı diyagramı

  • Sevkiyat çekirdek iş olduğundan diyagram Merkezi'nde yerleştirilir.Shipping is placed in the center of the diagram, because it's core to the business. Bu özelliği etkinleştirmek için diyagramda bir şey yok.Everything else in the diagram exists to enable this functionality.
  • İnsansız hava aracı ile Yönetim da çekirdek işletmeye olan.Drone management is also core to the business. İçin yönetim insansız hava aracı ile yakından ilgili işlevler içerir insansız hava aracı onarma ve kullanarak Tahmine dayalı analiz dronlarla hayat kurtarma Bakımı ve Bakım gerektiğinde tahmin etmek için.Functionality that is closely related to drone management includes drone repair and using predictive analysis to predict when drones need servicing and maintenance.
  • ETA analiz alma ve teslim için süre tahminleri sağlar.ETA analysis provides time estimates for pickup and delivery.
  • Üçüncü taraf taşıma bir paket tamamen insansız hava aracı tarafından sevk olamaz, farklı ulaşım yöntemleri zamanlamak uygulamayı etkinleştirir.Third-party transportation will enable the application to schedule alternative transportation methods if a package cannot be shipped entirely by drone.
  • Paylaşımı insansız hava aracı ile temel faaliyet olası bir uzantısıdır.Drone sharing is a possible extension of the core business. Şirket, aşırı insansız hava aracı ile kapasite belirli saatlerde olabilir ve aksi durumda boş olacak insansız kira.The company may have excess drone capacity during certain hours, and could rent out drones that would otherwise be idle. Bu özellik, ilk sürümde olmayacaktır.This feature will not be in the initial release.
  • Kameralı şirket içine daha sonra genişletebilir başka bir alandır.Video surveillance is another area that the company might expand into later.
  • Kullanıcı hesaplarını, faturalama, ve çağrı merkezi temel işin desteklenmesi alt etki alanları şunlardır.User accounts, Invoicing, and Call center are subdomains that support the core business.

Bu noktada işlem sırasında uygulama veya teknoloji hakkında herhangi bir karar yaptık yapmadıysanız, dikkat edin.Notice that at this point in the process, we haven't made any decisions about implementation or technologies. Bazı alt sistemler, dış yazılım sistemleri veya üçüncü taraf hizmetleri gerektirebilir.Some of the subsystems may involve external software systems or third-party services. Buna rağmen etki alanı modeli içinde eklenecek önemli olduğu için bu sistemleri ve Hizmetleri ile etkileşim kurmak uygulama gerekir.Even so, the application needs to interact with these systems and services, so it's important to include them in the domain model.

Not

Uygulamanın bir dış sistemde bağlıysa, dış sistemin veri şeması veya API uygulamanıza, sonuçta Mimari Tasarım ödün sızıntı oluşturacaktır sokması mümkündür.When an application depends on an external system, there is a risk that the external system's data schema or API will leak into your application, ultimately compromising the architectural design. Bu, modern en iyi uygulamaları takip edemez ve karışık veri şemaları ya da eski API'ler kullanabilir eski sistemlerle özellikle geçerlidir.This is particularly true with legacy systems that may not follow modern best practices, and may use convoluted data schemas or obsolete APIs. Bu durumda, bu dış sistemler ve uygulama arasında iyi tanımlanmış bir sınır olması önemlidir.In that case, it's important to have a well-defined boundary between these external systems and the application. Kullanmayı Strangler düzeni veya bozulma önleyici katman düzeni bu amaç için.Consider using the Strangler pattern or the Anti-Corruption Layer pattern for this purpose.

Sınırlanmış Bağlamlar tanımlayınDefine bounded contexts

Etki alanı modeli gerçek dünya şeyler temsillerini içerecektir — kullanıcılar, dronlarla hayat kurtarma, paketleri ve benzeri.The domain model will include representations of real things in the world — users, drones, packages, and so forth. Ancak, sistem her bir parçası için aynı şey aynı gösterimleri kullanması gerektiğini anlamına gelmez.But that doesn't mean that every part of the system needs to use the same representations for the same things.

Örneğin, insansız hava aracı onarma ve Tahmine dayalı analiz işleyen alt sistemler, kendi bakım geçmişi, mesafe, yaş, model numarası, performans özellikleri ve benzeri gibi birçok fiziksel özelliklerini insansız temsil etmek gerekir.For example, subsystems that handle drone repair and predictive analysis will need to represent many physical characteristics drones, such as their maintenance history, mileage, age, model number, performance characteristics, and so on. Ancak, bir dağıtım zamanlamak için zaman olduğunda, bunları hakkında düşünmeniz gerekmez.But when it's time to schedule a delivery, we don't care about those things. Zamanlama alt sistemi yalnızca bir insansız hava aracı ile olup ve alma ve teslim ETA bilmesi gerekir.The scheduling subsystem only needs to know whether a drone is available, and the ETA for pickup and delivery.

Tek bir modelde hem de bu alt sistemler oluşturmaya çalıştık, gereksiz derecede karmaşık olurdu.If we tried to create a single model for both of these subsystems, it would be unnecessarily complex. Değişiklikleri ayrı alt sistemler üzerinde çalışan birden çok ekipler karşılamak gerekeceğinden, ayrıca daha zor modelinin zamanla evrim olacak.It would also become harder for the model to evolve over time, because any changes will need to satisfy multiple teams working on separate subsystems. Bu nedenle, bu genellikle aynı iki farklı bağlamdan gerçek varlık (Bu durumda, bir insansız hava aracı) temsil eden ayrı modelleri tasarlamak iyidir.Therefore, it's often better to design separate models that represent the same real-world entity (in this case, a drone) in two different contexts. Her model, yalnızca özellik ve kendi belirli bağlamı içinde ilgili olan öznitelikleri içerir.Each model contains only the features and attributes that are relevant within its particular context.

Burada DDD kavramını sınırlanmış Bağlamlar dönüştürülerek.This is where the DDD concept of bounded contexts comes into play. Sınırlanmış bağlam yalnızca belirli bir etki alanı modeli burada geçerli bir etki alanı içinde sınırıdır.A bounded context is simply the boundary within a domain where a particular domain model applies. Önceki diyagramın bakarak, işlevleri, çeşitli işlevleri tek etki alanı modeli mi paylaşacak göre gruplandırabilirsiniz.Looking at the previous diagram, we can group functionality according to whether various functions will share a single domain model.

Sınırlanmış Bağlamlar diyagramı

Sınırlanmış Bağlamlar birbirlerinden mutlaka yalıtılmış değildir.Bounded contexts are not necessarily isolated from one another. Bu diyagramda, burada iki sınırlanmış Bağlamlar etkileşim yerler sınırlanmış Bağlamlar bağlanma düz çizgiler temsil eder.In this diagram, the solid lines connecting the bounded contexts represent places where two bounded contexts interact. Örneğin, sevkiyat, müşterilerle ilgili bilgileri almak için kullanıcı hesaplarında ve dronlarla hayat kurtarma fleet gelen zamanlamak üzere insansız hava aracı ile yönetim bağlıdır.For example, Shipping depends on User Accounts to get information about customers, and on Drone Management to schedule drones from the fleet.

Kitaptaki etki alanı Odaklı Tasarım, başka bir sınırlanmış bağlam ile etkileşim kurduğunda, bir etki alanı modeli bütünlüğünü korumak için çeşitli desenlerden Eric Evans açıklar.In the book Domain Driven Design, Eric Evans describes several patterns for maintaining the integrity of a domain model when it interacts with another bounded context. Ana ilkeleri mikro hizmetler, iyi tanımlanmış API'ler aracılığıyla iletişim kurar biridir.One of the main principles of microservices is that services communicate through well-defined APIs. Bu yaklaşım, Evans açık konak hizmeti ve dil yayımlanan çağrıları için iki deseni karşılık gelir.This approach corresponds to two patterns that Evans calls Open Host Service and Published Language. Açık konak hizmeti fikri, diğer alt sistemlerinin onunla iletişim kurmak için bir alt biçimsel bir protokol (API) tanımlar değildir.The idea of Open Host Service is that a subsystem defines a formal protocol (API) for other subsystems to communicate with it. Yayımlanan bir dil diğer ekipler istemciler yazmak için kullanabileceğiniz bir formda API yayımlayarak bu fikir genişletir.Published Language extends this idea by publishing the API in a form that other teams can use to write clients. Üzerinde bu bölümde API tasarımı, kullanmayı ele Openapı belirtimi (eski adıyla Swagger) REST API'leri için dilden arabirimi açıklamalar tanımlamak için JSON veya YAML biçiminde ifade edilir.In the chapter on API Design, we discuss using OpenAPI Specification (formerly known as Swagger) to define language-agnostic interface descriptions for REST APIs, expressed in JSON or YAML format.

Bu yolculuğu geri kalanı için biz sevkiyat sınırlanmış bağlam üzerinde odaklanır.For the rest of this journey, we will focus on the Shipping bounded context.

Taktiksel DDDTactical DDD

DDD stratejik aşaması sırasında iş etki alanını eşleyeceğiniz ve tanımlama sınırlanmış Bağlamlar, etki alanı modelleri için.During the strategic phase of DDD, you are mapping out the business domain and defining bounded contexts for your domain models. Taktiksel DDD, etki alanı modellerini daha hassas tanımlamanız gerekir.Tactical DDD is when you define your domain models with more precision. Taktiksel desenleri, tek bir sınırlanmış bağlam içinde uygulanır.The tactical patterns are applied within a single bounded context. Bir mikro hizmet mimarisinde toplama desenleri ve varlık içinde özellikle ilgi duyuyoruz.In a microservices architecture, we are particularly interested in the entity and aggregate patterns. Bu desenleri uygulama yardımcı oluyor uygulamamız hizmetler için doğal sınırlara tanımlamak için (bkz sonraki bölümde).Applying these patterns will help us to identify natural boundaries for the services in our application (see next chapter). Genel bir ilke olarak bir mikro hizmet, bir toplama'dan küçük olmamalıdır ve sınırlanmış bağlam şundan büyük olmalıdır.As a general principle, a microservice should be no smaller than an aggregate, and no larger than a bounded context. İlk olarak biz taktiksel desenleri gözden geçirelim.First, we'll review the tactical patterns. Biz bunları sevkiyat sınırlanmış bağlam içinde insansız hava aracı ile teslimat uygulaması için uygulayacağınız sonra.Then we'll apply them to the Shipping bounded context in the Drone Delivery application.

Taktiksel desenleri genel bakışOverview of the tactical patterns

Bu bölümde kısa bir özeti taktiksel DDD desenlerini, bunu zaten ile DDD hakkında bilginiz varsa, büyük olasılıkla bu bölümü atlayabilirsiniz.This section provides a brief summary of the tactical DDD patterns, so if you are already familiar with DDD, you can probably skip this section. Daha ayrıntılı olarak bölümlerde 5 desenleri açıklanan – 6 ve Eric Evans kitabın Implementing Domain-Driven tasarım Vaughn Vernon tarafından.The patterns are described in more detail in chapters 5 – 6 of Eric Evans' book, and in Implementing Domain-Driven Design by Vaughn Vernon.

Etki alanı odaklı tasarım desenlerini taktiksel diyagramı

Varlıkları.Entities. Zaman içerisinde devam eden benzersiz bir kimliğe sahip bir nesne bir varlıktır.An entity is an object with a unique identity that persists over time. Örneğin, bir bankacılık uygulamasında varlıklar müşteriler ve hesapları olacaktır.For example, in a banking application, customers and accounts would be entities.

  • Bir varlık varlığını almak veya aramak için kullanılan sisteminde benzersiz bir tanımlayıcıya sahiptir.An entity has a unique identifier in the system, which can be used to look up or retrieve the entity. Bu tanımlayıcı, her zaman doğrudan kullanıcılara sunulur anlamına gelmez.That doesn't mean the identifier is always exposed directly to users. Bir GUID ya da bir veritabanını birincil anahtarda olabilir.It could be a GUID or a primary key in a database.
  • Bir kimlik birden çok sınırlanmış Bağlamlar kapsayabilir ve uygulamanın ömründen uzun dayanabileceği.An identity may span multiple bounded contexts, and may endure beyond the lifetime of the application. Örneğin, banka hesabı numarası veya kamu verilen kimlikleri ömrünü belirli bir uygulama için bağlı değil.For example, bank account numbers or government-issued IDs are not tied to the lifetime of a particular application.
  • Bir varlığın özniteliklerini zaman içinde değişebilir.The attributes of an entity may change over time. Örneğin, bir kişinin adını veya adresini değiştirebilir, ancak bunlar yine de aynı kişidir.For example, a person's name or address might change, but they are still the same person.
  • Bir varlık, diğer varlıklara başvurular barındırabilir.An entity can hold references to other entities.

Değer nesneleri.Value objects. Bir değer nesnesi kimliksiz sahiptir.A value object has no identity. Bu, yalnızca öznitelik değerleri, kendi tarafından tanımlanır.It is defined only by the values of its attributes. Değer nesneleri ayrıca büyük/küçük harf sabittir.Value objects are also immutable. Bir değer nesnesi güncelleştirmek için her zaman eski değiştirmek için yeni bir örneğini oluşturun.To update a value object, you always create a new instance to replace the old one. Değer nesnelerinin, etki alanı mantığı kapsülleyen yöntemleri olabilir, ancak bu yöntemlerin herhangi bir yan etkisi nesnenin durumuna sahip olmalıdır.Value objects can have methods that encapsulate domain logic, but those methods should have no side-effects on the object's state. Renkler, tarih ve saat ve para birimi değerleri değeri nesnelerin tipik örneklerindendir.Typical examples of value objects include colors, dates and times, and currency values.

Toplamlar.Aggregates. Toplama, bir veya daha fazla varlık tutarlılık sınırlarından tanımlar.An aggregate defines a consistency boundary around one or more entities. Tam olarak bir varlıkta bir toplama köküdür.Exactly one entity in an aggregate is the root. Arama yapılır kullanarak kök varlığın tanımlayıcısı.Lookup is done using the root entity's identifier. Diğer tüm varlıklar ve toplam kökün alt öğesi olan ve aşağıdaki işaretçileri kök tarafından başvurulan.Any other entities in the aggregate are children of the root, and are referenced by following pointers from the root.

Bir toplama amacı, işlem okuduğunuzda model sağlamaktır.The purpose of an aggregate is to model transactional invariants. Gerçek dünyada ilişkilerinin karmaşık webs sahipseniz.Things in the real world have complex webs of relationships. Müşteriler sipariş oluşturur, siparişler ürünleri içeren, ürün tedarikçileri sahip ve benzeri.Customers create orders, orders contain products, products have suppliers, and so on. Nasıl uygulama birkaç ilgili nesneleri değiştirirse, tutarlılığı garanti etmez?If the application modifies several related objects, how does it guarantee consistency? Nasıl biz okuduğunuzda izlemek ve bunları zorunlu?How do we keep track of invariants and enforce them?

Geleneksel uygulama tutarlılığı zorlamak için veritabanı işlemleri genellikle kullandınız.Traditional applications have often used database transactions to enforce consistency. Dağıtılmış bir uygulamada, ancak, uygun değildir.In a distributed application, however, that's often not feasible. Bir tek iş işlem birden çok veri deposu kapsayabilir veya uzun süre çalışan olabilir veya üçüncü taraf hizmetleri gerektirebilir.A single business transaction may span multiple data stores, or may be long running, or may involve third-party services. Sonuç olarak etki alanı için gerekli okuduğunuzda zorlamak için veri katmanı uygulaması aittir.Ultimately it's up to the application, not the data layer, to enforce the invariants required for the domain. Hangi toplamalar model yöneliktir olmasıdır.That's what aggregates are meant to model.

Not

Alt varlıklar olmadan tek bir varlık, bir toplama oluşabilir.An aggregate might consist of a single entity, without child entities. Bir toplama kılan işlem sınırıdır.What makes it an aggregate is the transactional boundary.

Etki alanınızı ve uygulama hizmetleri.Domain and application services. DDD terminolojisinde, bir hizmeti herhangi bir durumu tutulmadan bazı mantığını uygulayan bir nesnedir.In DDD terminology, a service is an object that implements some logic without holding any state. Evans ayıran arasında etki alanı Hizmetleri, etki alanı mantığı kapsülleyen ve uygulama hizmetleri, kullanıcı kimlik doğrulaması veya SMS göndermek gibi teknik işlevleri sağlayın İleti.Evans distinguishes between domain services, which encapsulate domain logic, and application services, which provide technical functionality, such as user authentication or sending an SMS message. Etki Alanı Hizmetleri, genellikle birden çok varlık kapsayan model davranışı için kullanılır.Domain services are often used to model behavior that spans multiple entities.

Not

Terim hizmet yazılım geliştirme aşırı yüklendi.The term service is overloaded in software development. Burada, mikro hizmetler için doğrudan ilgili değildir.The definition here is not directly related to microservices.

Etki alanı olayları.Domain events. Etki alanı olayları bir şey olduğunda, sistemin diğer bölümlerini bildirmek için kullanılabilir.Domain events can be used to notify other parts of the system when something happens. Adından da anlaşılacağı gibi etki alanı olayları etki alanı içinde anlamı.As the name suggests, domain events should mean something within the domain. Örneğin, "bir kaydı bir tabloya eklenen" bir etki alanı olayı değil.For example, "a record was inserted into a table" is not a domain event. "Bir teslim iptal edildi" etki alanı bir olaydır."A delivery was cancelled" is a domain event. Etki alanı olayları bir mikro hizmet mimarisinde yakından ilgili olan.Domain events are especially relevant in a microservices architecture. Mikro hizmetler dağıtılan ve veri depoları paylaşmayın olduğundan, etki alanı olayları birbiriyle koordine etmek mikro hizmetlere yönelik bir yol sağlar.Because microservices are distributed and don't share data stores, domain events provide a way for microservices to coordinate with each other. Bu bölümde hizmetler arası iletişim zaman uyumsuz Mesajlaşma daha ayrıntılı olarak açıklanır.The chapter Interservice communication discusses asynchronous messaging in more detail.

Fabrikaları, depolar ve modüller gibi burada listelenmeyen birkaç diğer DDD deseni vardır.There are a few other DDD patterns not listed here, including factories, repositories, and modules. Bunlar ne zaman bir mikro hizmet uygulama için yararlı desenleri olabilir, ancak bunlar mikro hizmet arasındaki sınırları tasarlarken daha az uygundur.These can be useful patterns for when you are implementing a microservice, but they are less relevant when designing the boundaries between microservice.

İnsansız hava aracı ile teslimat: Uygulama desenleriDrone delivery: Applying the patterns

Biz, sevkiyat sınırlanmış bağlam işlemesi senaryoları ile başlayın.We start with the scenarios that the Shipping bounded context must handle.

  • Bir müşteri insansız hava aracı ile teslimat hizmeti ile kayıtlı bir iş mal almak üzere insansız hava aracı isteğinde bulunabilirsiniz.A customer can request a drone to pick up goods from a business that is registered with the drone delivery service.
  • Gönderen bir etiketi (barkod veya RFID) paketi put oluşturur.The sender generates a tag (barcode or RFID) to put on the package.
  • Bir insansız hava aracı almak ve bir paket kaynak konumundan hedef konuma sunun.A drone will pick up and deliver a package from the source location to the destination location.
  • Bir müşteri bir teslim zamanlarken sistemi rota bilgilerini, hava koşulları ve geçmiş veriler temel alınarak bir ETA sağlar.When a customer schedules a delivery, the system provides an ETA based on route information, weather conditions, and historical data.
  • İnsansız hava aracı uçuş modunda olduğunda, bir kullanıcının geçerli konumu ve en son ETA izleyebilirsiniz.When the drone is in flight, a user can track the current location and the latest ETA.
  • Müşteri, bir insansız hava aracı paketi çekilen kadar bir teslim iptal edebilirsiniz.Until a drone has picked up the package, the customer can cancel a delivery.
  • Müşteri, teslimat tamamlandığında bildirimde bulunulur.The customer is notified when the delivery is completed.
  • Gönderen, müşteriden bir imza veya parmağınızı yazdırma biçiminde teslim onay isteyebilir.The sender can request delivery confirmation from the customer, in the form of a signature or finger print.
  • Kullanıcılar tamamlanmış bir teslimat geçmişi bakabilirsiniz.Users can look up the history of a completed delivery.

Bu senaryolar aşağıdaki geliştirme ekibi belirlenen varlıkları.From these scenarios, the development team identified the following entities.

  • TeslimDelivery
  • PaketPackage
  • İnsansız hava aracıDrone
  • HesapAccount
  • OnayConfirmation
  • BildirimNotification
  • EtiketTag

İlk dört, teslim, paket, insansız hava aracı ve hesabı tüm toplamalar işlem tutarlılığı sınırlarını temsil eder.The first four, Delivery, Package, Drone, and Account, are all aggregates that represent transactional consistency boundaries. Onaylar ve bildirimler alt varlıklar teslimat ve etiketleri paketlerin alt varlıklar.Confirmations and Notifications are child entities of Deliveries, and Tags are child entities of Packages.

Değer nesneleri konumu, ETA PackageWeight ve PackageSize bu tasarım içerir.The value objects in this design include Location, ETA, PackageWeight, and PackageSize.

Göstermek için bir UML diyagram teslim toplamanın aşağıdadır.To illustrate, here is a UML diagram of the Delivery aggregate. Hesap, paket ve insansız hava aracı gibi başka toplamalar, başvurularını tuttuğu dikkat edin.Notice that it holds references to other aggregates, including Account, Package, and Drone.

UML diyagram teslim toplama

İki etki alanı olay vardır:There are two domain events:

  • Değerlendirme sırasında bir insansız hava aracı olsa da, insansız hava aracı ile varlık insansız hava'nın konumunu ve durumunu (uçuşan, varış yerindeki) açıklayan DroneStatus olaylar gönderir.While a drone is in flight, the Drone entity sends DroneStatus events that describe the drone's location and status (in-flight, landed).

  • Teslim varlık, bir dağıtım aşaması değiştiğinde DeliveryTracking olayları gönderir.The Delivery entity sends DeliveryTracking events whenever the stage of a delivery changes. Bunlar, DeliveryCreated, DeliveryRescheduled DeliveryHeadedToDropoff ve DeliveryCompleted içerir.These include DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff, and DeliveryCompleted.

Bu olaylar'ın etki alanı modeli içinde anlamlı şey verdiğine dikkat edin.Notice that these events describe things that are meaningful within the domain model. Bunlar, etki alanınız hakkında bir şeyi anlatma ve belirli bir programlama dili yapısı bağlı değildir.They describe something about the domain, and aren't tied to a particular programming language construct.

Geliştirme ekibi bir daha fazla alan düzgünce şimdiye kadar anlatılan varlıkları hiçbirine uymayan işlevine, belirledik.The development team identified one more area of functionality, which doesn't fit neatly into any of the entities described so far. Bazı sistem bölümlerinin zamanlama veya bir teslim güncelleştirme yer alan adımların tümünü koordine etmeleri gerekir.Some part of the system must coordinate all of the steps involved in scheduling or updating a delivery. Bu nedenle, geliştirme ekibi iki eklenen etki alanı Hizmetleri tasarım: bir Zamanlayıcı , adımları, düzenler ve gözetmen , her durumunu izler adım, herhangi bir adım başarısız oldu veya zaman aşımına uğradı olup olmadığını algılamak için kullanılır. Bu bir çeşididir Zamanlayıcı Aracısı Gözetmeni düzeni.Therefore, the development team added two domain services to the design: a Scheduler that coordinates the steps, and a Supervisor that monitors the status of each step, in order to detect whether any steps have failed or timed out. This is a variation of the Scheduler Agent Supervisor pattern.

Düzeltilmiş etki alanı modeli diyagramı