Discovering the domain architecture through DDD
“Purpose of Domain Driven Design – Mitigate the burden of writing software under tough conditions.”
Start from the business!
First of all, when starting implementation of the Domain Driven Design methodology, we should have a good domain knowledge of the product we are going to build.
The classes and methods must be representation of the business. They should describe the domain requirements.
A big importance in implementation of DDD has the so called Ubiquitous language. Or in other words – using the same terminology with business description and technical classes implementation. For example – when it is discussed and described in the business requirements the order to be submitted, we should implement an object called Order, and a method called Submit, not “checkout“, “buy” or something else. That way the business and the technical people will speak the same language with common terminology and the understanding, support and maintenance will be better.
For DDD implementation we should use value types, private setters, factories.
When to use NoSQL (CounchDB, Cassandra, MongoDB,…)
- (Unpredictably) large volumes of data
- Semi-structured data coming in different forms and needing same treatment – polymorphic data
- Event stores
- Limited support for complex types (enums, etc.)
- Knowledge of the DB structure
- Indexing – if we have lots of columns, with index on them and lots of calls – we will have a problem with rebuilding all of the indexing and performance.
Polyglot persistence – take the best of relational and no-sql.
“If you are not in trouble with it”
…keep on using SQL” 🙂
Suggest we are building an application considering creating the back-end by parts. Every command we run is either writing or reading operation. Split the business logic into 2 parts – one for reading and one for writing.
Complexity in web site – in one domain we have always actions to perform – like write and update and also something to read from the data store.
Domain becomes a bounded context.
- Simplification of the design
- Optimizing and enhancing the scalability.
CQRS allows us to do things today in different big manner.
It allows us to build business complexity.
Most of the systems are CRUD.
The problem is that the workflow behind the representation is being extended, modified.
The workflow is a flowchart. Each statement is a workflow. And we have to use plain code.
With CQRS you can choose distinct approach – using messages.
“CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.” (http://martinfowler.com/bliki/CQRS.html).
UX-first design methodology
The normal and most common process of developing an application is:
- First creating the DB.
- Then the ORM, business logic and all the components that are constructing the back-end and at the end.
- On top of this we create and adapt some front-end.
UX-first is a bit upside-down:
- Build up UI forms
- Define workflows
- Connect the workflows to the existing BL
In this approach for each screen we have a basic flowchart.
The following sequence of operations is done while following the UX-firs design flow:
- Determine what comes in and out and create view-model classes
- Make application layer endpoints receive/return such DTO classes
- Make application layer orchestrate tasks on layers down the stach
* Notes from Dino Esposito: Software architecture days, Sofia, 2015