Building Microservices Through Event-Driven Architecture, Part 1: Application-Specific Business Rules

 image source:  https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html  

today, architectures such as the onion or hexagonal patterns play an important role in the testability and maintenance of code, its independence from external frameworks, etc. in this tutorial, i will show you how to use clean architecture, with methods and tools such as domain-driven design (ddd), test (behavior) driven development (tdd), cqrs, event sourcing, containerization, oauth2, and oidc to build a microservices architecture.

for more information on clean architecture, i suggest you read  this article  by robert c. martin (uncle bob).

 the dependency rule 

according to  uncle bob  ,

"the concentric circles [in the graphic above] represent different areas of software. in general, the further in you go, the higher level the software becomes. the outer circles are mechanisms. the inner circles are policies.

"the overriding rule that makes this architecture work is the dependency rule. this rule says that source code dependencies can only point inwards. nothing in an inner circle can know anything at all about something in an outer circle. in particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. that includes functions, classes. variables, or any other named software entity.

"by the same token, data formats used in an outer circle should not be used by an inner circle, especially if those formats are generated by a framework in an outer circle. we don't want anything in an outer circle to impact the inner circles."

  - robert c. martin (uncle bob)  

cqrs separate commands from queries

commands are operations that change the application state and return no data. queries are operations that return data but do not change application state.

so, cqrs will be a very useful concept in the world of microservices by creating our application with two databases:

1. a relational database which is optimized for writing on the command side.
2. a nosql database on the query side in order to read data as fast as possible. since most applications read data much more often than they write data, in our approach of containerization, we can scale the command side on two pods and query side on 10 pods, for example

cqrs fits into a domain-driven design model. ddd focuses on building rich domain models to tackle complex business logic.

changing the data causes more bugs. so, having a clear perception of which part of the application changes the data and which part of the application does not change the data will help with maintainability and debugging

event sourcing stores all changes to an object as a series of events in an event store
 https://eventstore.org/ 

i will use this concept to build the following:

• domain service implements domain-related concepts (entity, value object, aggregates, domain events), records a command in a relational database, and an event in the event store — all as a unit for the purpose of data change.
• a producer takes the event from the event store and sends it to the service bus (an event store is an 'append only' table and uses ubiquitous language).
• a consumer, the subscriber to the service bus, takes the event from the service bus and registers it as pre-computed data to a nosql database.
• the readmodel service queries the nosql database.
• everything that happens is saved in the event store.

i will build a system that helps speakers and attendees to register and follow events (conferences, talks, meetups, etc...).

my project is structured as follows:

• the innermost layer holds the core domain. it contains our domain objects and business rules and defines our external interfaces.

• databases, network connections, filesystem, ui, or special frameworks are not allowed.

• the core domain has no knowledge of anything outside of itself.

• those dependencies, and their implementations, are injected into our core domain using interfaces.

 test driven development 

this layer points to the core domain and contains the application-specific business rules.

the above code allows us to:

• orchestrate the data flow and use the domain model.

• have no dependency to a database, ui, or special frameworks.

this layer holds the web, ui, and presenter concerns. in the context of our api, this means it accepts input in the form of http requests over the network (post/put/patch/delete) and returns its output as json formatted content.

this layer holds the  database  and  gateway  concerns. here, we define the data access layer, repositories, etc.

it also contains the physical implementation of the interfaces defined in our domain layer

in the code below, we are implementing the "speech registration" use case:

to make my tests green, the first thing i need to do is implement  registerspeechusecase   : 

the overriding rule that makes this architecture work is the dependency rule. this rule says that, "source code dependencies can only point inwards. nothing in an inner circle can know anything at all about something in an outer circle." (  robert c. martin (uncle bob)  ).

it takes an input object as a command and then renders the interface:

then  registerspeechusecase    will look like this:

let us defines dependencies such as  iunitofwork  and  ispeechrepository  . these interfaces belong to the core domain and will be implemented in the infrastrucrure.

 ispeechrepository    needs a speech entity, so let's create it on the core domain.

in this stage, every thing compiles succesfully, but my tests failed:

as you can see, tests fails because i verify that  createasync    and  commit    are called. so, let us call:

here we're calling  speechrepository.createasync    and  iunitofwork.commit    on the  registerspeechusecase    class:

then we create a mock of  speechrepository.createasync  and  iunitofwork.commit    on the 'arrange' section of the unit test.

at this stage, all tests are green but my code coverage is not good enough:

for example, if i comment out this block my tests will succeed but my app will crash at runtime if the command is null.

let us add a new test to fix it:

finally, the code coverage is 100% for  logcorner.edusync.speech.application 

but what happens if i permute values?

var title = command.type;
var urlvalue = command.title;
var description = command.url;
var type = command.description;

all tests will succeed but my application will be in an invalid state because it will insert the title instead of the url.

i can fix this using  moqspeechrepository.verify    in test assertions, but i'll leave it like that and fix it when implementing my domain with the introduction of the values objects:

in the next post, i will implement the domain model.

source code is available here:  registerspeechusecase