The document discusses domain-driven design and decomposing software applications into modules and microservices to reduce complexity. It defines complexity as the number of things that must be considered when working with software. Decomposition techniques include identifying modules based on layers of abstraction that can replace each other. Microservices are independent services that scale independently, unlike monolithic applications. Domain-driven design maps software design to the business domain using ubiquitous language. The structure of microservices teams should mirror the communication structure of the organization.

1. @altoros
1
Domain-driven Design
by Siarhei Matsiukevich,
Cloud Engineer and Go Developer at Altoros
@altoros

2. @altoros
What is the main challenge in software development?

3. @altoros
How to measure application complexity
❖Complexity of all interfaces that application uses
❖+ Complexity of all interfaces that application provides
❖+ Complexity of application source code
For me, the definition of complexity is the amount of things you should keep
in mind when working with a software product.

4. @altoros
So, how we can deal with software complexity?
❖Become a genius
❖Improve the quality of source code
❖Decompose your app into smaller pieces

5. @altoros
Different ways of application decomposition

6. @altoros
How to identify that decomposition is good?
Loose coupling

7. @altoros
So what is the problem with that?

8. @altoros
How to identify modules?
❖Based on physical layers separation
❖To provide abstraction for components that CAN REPLACE EACH OTHER
Don’t just do it because your architecture is better if you have many
interfaces!

9. @altoros
Module identification based on physical layer
separation

10. @altoros
Module identification based on layer abstraction

11. @altoros
Microservices

12. @altoros
Can a separate class or module be a microservice?
Module should be transformed to a microservice when there is a
need to scale this module independently.

13. @altoros
Microservices vs. monolithic apps
Category Monolithic Microservice
Understandability Hard to maintain Easy to understand
Deployment Big Bang release Independent continuous
Tools Approved tools, languages, and
frameworks
Right tool for Job
Scalability Scale everything Scale bottleneck services
Project management Difficult to track More granular control
Quality Assurance Regression tests Localized test
Planning On a department level On a team level

14. @altoros
Domain-driven Design

15. @altoros
Bounded context

16. @altoros
An example of a ubiquitous language
public interface Customer {
public void changePersonalName(String firstName, String lastName);
public void relocateTo(PostalAddress changedPostalAddress);
public void changeHomeTelephone(Telephone telephone);
public void disconnectHomeTelephone();
public void primaryEmailAddress(EmailAddress emailAddress);
}
public interface Customer {
public void save(Customer customer);
public void remove(Customer customer);
public void findById(Integer id);
}

17. @altoros
Microservices: team
“Any organization that designs a system (defined broadly) will produce a design, which
structure is a copy of the organization's communication structure.”
--Melvyn Conway, 1967

18. @altoros
18
Don’t do it
1) Start from microservices
2)Work without DevOps
3)Create too many services
4)Forget to track latency

19. @altoros
19
Thank you!
Want more?
www.altoros.com
blog.altoros.com
twitter.com/altoros