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 can consider building application, considering creating the back-end by parts. Every command we run is either a command or read. Split the business logic into 2 parts – 1 for reading and 1 for writing.
Complexity in web site – in domain we have actions to perform and something to read.
Domain becomes a bounded context.
The benefits: Simplification of the design, Optimizing and enhancing the scalability. It allows to do things today in different big manner, allow to build business complexity. Most of the systems are CRUD. The problem is the workflow behind the representation in being extended, modified.. The workflow is a flowchart. Each statement is a workflow. And we have to use plain code. With CQRS – 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 by 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 workflows to existing BL
- For each screen have a basic flowchart
- 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