This week 5/2017

In this article I'd like to collect some ideas connected with Microservice Architecture.

1. Bounded context and organisational aspect.
In many sources there is recommendation to create small teams dedicated to one or a few microservices. One microservice should resolve a problem of one bounded context. A small team should well understand implemented part of domain (bounded domain) and should gather maximum "two-pizza team".

2. Possibility to scaling every service of application. 

Microservice architecture requires usage of many servers, that's why they have to be monitored and managed centrally. On each server works one instance of service but if we need more instances it is very easy to install it on more servers. This way it is possible to start new instance of service and shut down it if it is  needless. Another advantage of Microservice is that small application boot faster than big monolith and it is easy to deploy new code without outage.

3. Duplication of code

There is common opinion that much easier is to control monolith than Microservices. Martin Fowler recommends to try resolve business problem in monolith architecture and then eventually move into microservices. However this style have become fashionable and everyone tries his hands at it and it has nothing common to do with business needs... During migration process there is a lot of duplicated code between services. It could be also big problem. However my idea is to move shared parts of code into small utils jars.

4.  Latency time & lack of consistent = additional complexity

Common question is how to get consistency and availability concurrently? Answer is sad but it is impossible. Consistency requires to have shared database where every business operation locks updated or removed record.
However, firstly we have to remember that coding, transmitting and decoding message takes time, especially if services are situated in worldwide locations, transmission has significant influence.
Secondly, fault tolerant services move task to available instance of service.
Then, to have hight performance every service has its own database or even every instance of service. That's why in most cases there is used optimistic locking, data partitioning or CQRS and Event Sourcing. Sometimes it is not enough and some business decisions are required to be ready for border conditionals, ex. hotel's room reservation problem.

5. Interface development - contract problem
This subject is good known for SOA and Microservices as well. The common solution for SOA is to use the same wsdl file for producer and consumer but what if we have many different consumers and we need to extend our interface without engaging teams responsible for immutable services?
There is one way to do that - Consumer-Driven Contract. This approach requires to use only needed fields and inform producer about customer schema.


Resources:

1. https://martinfowler.com/articles/microservices.html 
2. https://martinfowler.com/articles/consumerDrivenContracts.html 
3. https://www.infoq.com/news/2015/12/soa-v-microservices 
4. http://blog.arungupta.me/microservice-design-patterns/ 
5. https://dzone.com/articles/application-pattern-consumer 
6. https://www.martinfowler.com/microservices/ 
7. http://microservices.io/patterns/microservices.html 
8. https://docs.pact.io/

This week 19/2016

This article is a summary of thoughts about implementing a piece of DDD in my application. This weekend I disinterred an old topic: How can I design something similar to the DDD in my application and don't turn over all existing application? How can I gently get into.
In inherited application there is strongly used hibernate. Entities model looks like it tries to build a full domain model - they have states and behaviours. However all functionalities use entities in view (and Session on view pattern) and it is difficult to do hermetic model especially then all entity attributes has public setters and getters.

My idea were:

• to retrieves entities only to service level and then map them to immutable dto and dto use in views or if it was necessary map them to mutable Java Plain Object.
• change access type for data in entitles. Till now there was property access an there was impossible to remove setter method from entity. I prefer field access. It is much more transparent and allow to remove getters and setters which can be implemented by Lombok library.
• add new layer - application layer which collect a few independent functionalities and share them to controller.
• I changed packaging of my classes. Classes were included to packages split in order: layer name, functionality. Now I package my classes in order: functionality, layer, but I still thinking about removing layer part of packages and much more granulate functionality.
• reports contains data from many independent tables. I get data by native sql directly mapped to immutable dto.

Now I was focused on bounded domain model and how to resolve it in my application. In this application I should much more use CQRS pattern.


Anyway I think about some other implementation problems, ex. how should I implement JPA entities of bounded context? One context needs only a few attributes of all model, other needs some other but that attributes are archived in one db table.

I still looking for best solutions:)

Bellow I added a few interesting resources:

ddd series

ddd-in-practice

dddexample

domain-driven-design-with-java-ee-6

ddd-and-spring