docs: fix formating of document

Chapter-4-applying-tactical-domain-driven-design/README.adoc

@@ -36,10 +36,7 @@ Examples of strategic techniques include:
 - link:https://vladikk.com/2018/01/26/revisiting-the-basics-of-ddd/[Domain Categorization]
 - link:https://github.com/ddd-crew/context-mapping[Context Mapping]
 
-[NOTE]
-===
-You don't have to use all of them to be successfully. Treat DDD as pharmacy. You should choose the ones that fit your needs and the complexity of the system you are building.
-===
+NOTE: You don't have to use all of them to be successfully. Treat DDD as pharmacy. You should choose the ones that fit your needs and the complexity of the system you are building.
 
 Let's take a look at modelling process.
 
@@ -50,10 +47,7 @@ Large part of the process is strategic part. That show us how important is to un
 ==== Tactical
 Tactical techniques focus on solution implementation for problems that we already comprehend. They provide a set of patterns and <<building_blocks, building blocks>> that help developers apply the solution (domain model) in the code and maintain it in the long term.
 
-[NOTE]
-====
-Tactical patterns are used only in the _Contracts_ microservice due to its domain complexity.
-====
+NOTE: Tactical patterns are used only in the _Contracts_ microservice due to its domain complexity.
 
 == Case
 
@@ -126,10 +120,7 @@ Let's focus on business rules that we identified during the workshop.
 
 Let's take a look closer to this rule. __Previous Annex Must Be Signed__. This rule is connected with the relationship between the new and previous annex. This is invariant.
 
-[NOTE]
-====
-Invariant is a rule or condition that must always be true for a system to be considered in a valid state. It ensures the integrity and consistency of the domain model
-====
+NOTE: Invariant is a rule or condition that must always be true for a system to be considered in a valid state. It ensures the integrity and consistency of the domain model
 
 To enforce these business rules and maintain consistency, we need a robust way to protect invariant, especially in a concurrent environment.
 
@@ -139,7 +130,7 @@ That’s why the __Binding Contract__ <<entity,entity>> has to be promoted to <<
 
 image::Assets/aggregate_root_canvas.png[]
 
-IMPORTANT: Aggregate Root is pattern that solve specific problem. It is not a silver bullet. Aggregate root canvas will help you make this decision consciously and consider all aspect of design aggregate like invariants, concurency, performance. We are encouraging you to use it in your design process. Enoy!
+IMPORTANT: Aggregate Root is pattern that solve specific problem. It is not a silver bullet. "Aggregate Root Canvas" will help you make this decision consciously and consider all essential aspects like purpose, invariants, concurency, performance. We are encouraging you to use it in your design process.
 
 Let's proceed with and anlysis and take a look on __Annex__. Annexes are a part of the __Binding Contract__ <<aggregate,aggregate>>. They have to be uniquely identified and encapsulate business logic. We will model it as an <<entity, entity>>.
 
@@ -205,7 +196,7 @@ They enhance our domain model's expressiveness, prevent invalid object state and
 
 "Primitive Obsession" is a code smell where we use primitive types to represent domain concepts. 
 
-image::Assets/value_object_sets.png[300,300]
+image::Assets/value_object_sets.png[300,300,align=center]
 
 For e.g you can treat _SSN_ as _string_. _String_ allow put to field every character, but _SSN_ has specific format. Take a look at image above. You can see that _SSN_ is just only small subset of _string_ possible values.
 **Value object is precise and can validate format during object initialization.**
@@ -262,9 +253,7 @@ Aggregate roots are also transactional boundaries. All changes to the aggregate
 
 image::Assets/aggregate_root_internals.png[]
 
-[NOTE]
-
-When you are looking for boundaries of an aggregate, you should consider which data has to change together (has to be in the same transaction) and which data can be changed independently.
+NOTE: When you are looking for boundaries of an aggregate, you should consider which data has to change together (has to be in the same transaction) and which data can be changed independently.
 
 ==== Main characteristics of aggregate roots:
 - They enforce business rules and invariants internally
@@ -327,9 +316,7 @@ public interface IDomainEvent
 }
 ----
 
-[NOTE]
-
-Because of entities and aggregate root are highly encapsulated, domain events are the only way check if something happened in the domain model. They are used as assertion in unit tests that make they more business expressive.
+NOTE: Because of entities and aggregate root are highly encapsulated, domain events are the only way check if something happened in the domain model. They are used as assertion in unit tests that make they more business expressive.
 
 === Persistence Domain Model
 ==== Persistence Ignorance
@@ -405,10 +392,7 @@ In case of any issues, you can add nuget feed manually:
 
 You should now be able to restore and download the EvolutionaryArchitecture nuget packages from your Artifactory source within Rider.
 
-[NOTE]
-====
-The provided instruction is primarily intended for JetBrains Rider. However, the procedure for adding a NuGet package source in alternative IDEs like Visual Studio is quite similar.
-====
+NOTE: The provided instruction is primarily intended for JetBrains Rider. However, the procedure for adding a NuGet package source in alternative IDEs like Visual Studio is quite similar.
 
 === How to run Integration Tests?
 Running integration tests for both the `Fitnet` Modular Monolith and `Fitness.Contracts` applications involves similar steps, as the testing setup for both projects.