The way from DB-driven development to DDD Руслан ГатиятовДроид Лабсhttp://droidlabs.pro // https://planiro.com

1. Clarity2. Maintainability3. Extensibility4. Safety5. Stability6. Predictability7. Scaling8. Testability

What should we address?

General Rails problems1. DB driven thinking instead of business actions - I should persist this entity and this entity and also this one - create migration before test and actual code

2. REST confusion - POST /users creates user + organization + settings + default entities + etc

3. Code does not protect you from doing errors Entity1.create(...) should I also call Entity2.create(...) ?

General Rails problems4. Testing framework does not use business rules - hard to read tests (what is going on there?) - hard to isolate test - hard to maintain test - mocks and stubs usually violate encapsulation - very long tests with many checks per test - really slow tests that use whole framework (even zeus, spring, VCR) - TDD is being applied rarely

General Rails problems 5. Violation of SOLID principles: all layers are mixed up - DB calls in the views - views helper methods in models - business rules in controllers - hard to isolate layers

General Rails problems 6. Less code means == obscure code

7. World of opinionated conventions

8. Project == RAILS - Are you able to change Rails with any other web framework during 1 working day? 9. Write model is different from Read Model (Commands and Queries)

MVC - passive model - active model

The beginning

1. C = controller- interaction with user- calls to model layer- serialize data and return result

Controller

View2. V = view

- representation of results- JSON, XML, HTML, TXT, CSV, PDF, ...

what does V consist of? - view data (view model) - serializer (html, xml, json, ...)

Model3. M = business model (set of modules that implement business rules)

IMPORTANT:M != ActiveRecord::Base descendant (it was only a certain case)

It’s not enough to have only services layer.

DDDwhat does DDD imply? - ubiquitous language - layers of abstraction - bounded context - conventions about domain entities

DDD - bounded contextBounded context is a central point in DDD

what does M consist of?

Layers of abstraction:- Application Layer- Domain Layer- Infrastructure Layer

Model

what is Application Layer?

defines interaction interface to get access to different system actions (commands) and stored data (queries)

Commands + Queries => CQRS principle

Examples: command 'accounts.register_user' query 'pm.reporting.user_productivity_report'

Application Layer

Implements business logic using ubiquitous language including constraints, permissions checks, etc

1) Entity2) Value Object3) Aggregate4) Service5) Repository6) Factory7) Domain events

Domain Layer

provides access to all external services- repositories- http clients- file utils- configs- websocket clients- amqp clients- etc

Infrastructure Layer

Why DDD?How much time do you need to

- understand an issue- find a problem place- think about all possible side effects

for a system that has one end point for all UPDATE operations VS system having 1 endpoint per business action?

DDD is intended to solve business problems not thinking about implementation from the beginning. Ubiquitous language helps customers and developers to talk using the same language.

Questions to expertsWhy does it change?When does it change?How often?Who causes it?By which rules?What consequences?

What does DDD provides?

1. DSL && Ubiquitous language2. Naming conventions for different layers3. Web-framework is a detail of implementation4. Database is a detail of implementation5. High Cohesion and Low Coupling of your code