+ All Categories
Home > Technology > Domain-driven Design

Domain-driven Design

Date post: 10-Jan-2017
Category:
Upload: altoros
View: 495 times
Download: 0 times
Share this document with a friend
19
@altoros 1 Domain-driven Design by Siarhei Matsiukevich, Cloud Engineer and Go Developer at Altoros @altoros
Transcript
Page 1: Domain-driven Design

@altoros

1

Domain-driven Design

by Siarhei Matsiukevich,Cloud Engineer and Go Developer at Altoros

@altoros

Page 2: Domain-driven Design

@altoros

What is the main challenge in software development?

Page 3: Domain-driven Design

@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.

Page 4: Domain-driven Design

@altoros

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

Page 5: Domain-driven Design

@altoros

Different ways of application decomposition

Page 6: Domain-driven Design

@altoros

How to identify that decomposition is good?Loose coupling

Page 7: Domain-driven Design

@altoros

So what is the problem with that?

Page 8: Domain-driven Design

@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!

Page 9: Domain-driven Design

@altoros

Module identification based on physical layer separation

Page 10: Domain-driven Design

@altoros

Module identification based on layer abstraction

Page 11: Domain-driven Design

@altoros

Microservices

Page 12: Domain-driven Design

@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.

Page 13: Domain-driven Design

@altoros

Microservices vs. monolithic apps

Category Monolithic Microservice

Understandability Hard to maintain Easy to understandDeployment Big Bang release Independent continuousTools Approved tools, languages,

and frameworksRight tool for Job

Scalability Scale everything Scale bottleneck services Project management Difficult to track More granular controlQuality Assurance Regression tests Localized testPlanning On a department level On a team level

Page 14: Domain-driven Design

@altoros

Domain-driven Design

Page 15: Domain-driven Design

@altoros

Bounded context

Page 16: Domain-driven Design

@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);}

Page 17: Domain-driven Design

@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

Page 18: Domain-driven Design

@altoros

18Don’t do it

1)Start from microservices2)Work without DevOps3)Create too many services 4)Forget to track latency

Page 19: Domain-driven Design

@altoros

19

Thank you!Want more?

www.altoros.comblog.altoros.com

twitter.com/altoros


Recommended