You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/azure/microservices-architecture/includes/2-monolith-microservices.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
Fabrikam integrated their new drone service into their existing application. They realize that this solution isn't a good long-term plan for their application. The existing system is a monolithic architecture, but what exactly does that mean?
1
+
Fabrikam integrated their new drone service into their existing application. They realize this solution isn't a good long-term plan for their application. The existing system is a monolithic architecture, but what exactly does that mean?
Copy file name to clipboardExpand all lines: learn-pr/azure/microservices-architecture/includes/4-monolith-performance.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,4 +18,4 @@ The package service was identified as a critical part of the business and was or
18
18
19
19
Because the package service is in the monolith, the team can't operate autonomously. They have to rely on shared data and data structures. They're also unable to iterate as quickly as they need. Along with the performance and scalability issues, this service is identified as a prime candidate for a microservice.
20
20
21
-
Let's take a closer look at how Fabrikam can analyze and decompose their application to take advantage of a microservices architecture.
21
+
Let's take a closer look at how Fabrikam can analyze and decompose their application to take advantage of a microservices architecture.
Copy file name to clipboardExpand all lines: learn-pr/azure/microservices-architecture/includes/5-analyze-decompose.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,11 +54,11 @@ Tactical DDD is when you define your domain models with more precision. The tact
54
54
55
55
There are several tactical DDD patterns to consider:
56
56
57
-
-**Entities:** An entity is an object with a unique identity that persists over time. For example, in a banking application, customers and accounts are entities.
58
-
-**Value objects:** A value object has no identity. The values of its attributes define it, and it's immutable. Typical examples of value objects include colors, dates and times, and currency values.
59
-
-**Aggregates:** An aggregate defines a consistency boundary around one or more entities. The purpose of an aggregate is to model transactional invariants. Things in the real world have complex webs of relationships. Customers create orders, orders contain products, products have suppliers, and so on. If the application modifies several related objects, how does it guarantee consistency? How do we keep track of invariants and enforce them?
60
-
-**Domain and application services:** In DDD terminology, a service is an object that implements some logic without holding any state. Evans distinguishes between domain services, which encapsulate domain logic, and application services, which provide technical functionality. Application services typically include technical functionality such as user authentication or sending an SMS message. Domain services are often used to model behavior that spans multiple entities.
61
-
-**Domain events:** Domain events can be used to notify other parts of the system when something happens. As the name suggests, domain events should mean something within the domain. For example, "a record was inserted into a table" isn't a domain event. "A delivery was canceled" is a domain event. Domain events are especially relevant in a microservices architecture. Because microservices are distributed and don't share data stores, domain events provide a way for microservices to coordinate with each other.
57
+
-**Entities**: An entity is an object with a unique identity that persists over time. For example, in a banking application, customers and accounts are entities.
58
+
-**Value objects**: A value object has no identity. The values of its attributes define it, and it's immutable. Typical examples of value objects include colors, dates and times, and currency values.
59
+
-**Aggregates**: An aggregate defines a consistency boundary around one or more entities. The purpose of an aggregate is to model transactional invariants. Things in the real world have complex webs of relationships. Customers create orders, orders contain products, products have suppliers, and so on. If the application modifies several related objects, how does it guarantee consistency? How do we keep track of invariants and enforce them?
60
+
-**Domain and application services**: In DDD terminology, a service is an object that implements some logic without holding any state. Evans distinguishes between domain services, which encapsulate domain logic, and application services, which provide technical functionality. Application services typically include technical functionality such as user authentication or sending an SMS message. Domain services are often used to model behavior that spans multiple entities.
61
+
-**Domain events**: Domain events can be used to notify other parts of the system when something happens. As the name suggests, domain events should mean something within the domain. For example, "a record was inserted into a table" isn't a domain event. "A delivery was canceled" is a domain event. Domain events are especially relevant in a microservices architecture. Because microservices are distributed and don't share data stores, domain events provide a way for microservices to coordinate with each other.
62
62
63
63
64
64
@@ -78,7 +78,7 @@ The value objects in this design include Location, ETA, PackageWeight, and Packa
78
78
79
79
There are two domain events:
80
80
81
-
- While a drone is in flight, the drone entity sends DroneStatus events that describe the drone's location and status, for example, in-flight, landed.
81
+
- While a drone is in flight, the drone entity sends DroneStatus events that describe the drone's location and status such as in-flight and landed.
82
82
- The delivery entity sends DeliveryTracking events whenever the stage of a delivery changes. These events include DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff, and DeliveryCompleted.
83
83
84
84
Notice that these events describe things that are meaningful within the domain model. They describe something about the domain and aren't tied to a particular programming language construct.
For more background on domain-driven design, we recommend *Domain-Driven Design* by Eric Evans. This book first introduced the term, domain-driven design. Another good reference is *Implementing Domain-Driven Design* by Vaughn Vernon.
12
+
For more background on domain-driven design, we recommend *Domain-Driven Design* by Eric Evans. This book first introduced the term, domain-driven design. Another good reference is *Implementing Domain-Driven Design* by Vaughn Vernon.
0 commit comments