Fix typos
This commit is contained in:
@@ -257,7 +257,7 @@ This change might be calculated by dirty checking or we might just override enti
|
||||
Third option is _Let's make implicit explicit_ and actually call this state change A->B an **event**.
|
||||
After all, event-driven architecture is all about promoting state changes as domain events.
|
||||
|
||||
Thanks to this our domain model may become immutable and just return events as results of invocking a command like so:
|
||||
Thanks to this our domain model may become immutable and just return events as results of invoking a command like so:
|
||||
|
||||
```java
|
||||
public BookPlacedOnHold placeOnHold(AvailableBook book) {
|
||||
|
||||
@@ -25,7 +25,7 @@ in **book hold failed** event, as it is depicted below:
|
||||
|
||||

|
||||
|
||||
Taking a look at the domain description again, we find out that each patron can have no more than 1 **overdue checkouts**.
|
||||
Taking a look at the domain description again, we find out that each patron can have no more than 2 **overdue checkouts**.
|
||||
In such situation, every attempt to **place a book on hold** should fail:
|
||||
|
||||

|
||||
@@ -53,7 +53,7 @@ And here is the last example, partially covered before:
|
||||
|
||||

|
||||
|
||||
### Regular patron
|
||||
### Researcher patron
|
||||
|
||||
In the previous part of this paragraph we focused on a *regular patron* only. Let's have a look at *researcher patron* now.
|
||||
The domain description clearly states that **any** patron with more than 2 **overdue checkouts** will get a rejection
|
||||
|
||||
Reference in New Issue
Block a user