Learning DDD and CQRS

Question

I'm new to DDD and CQRS and I'm planning to build a simple application to improve my skills a bit. What I'm planning to do is a simple Taxi Corp application.

Requirements:

1. Client orders a taxi.
2. Client can have only one order at a time.
3. Driver picks an order.
4. Driver can have only one order at a time.
5. Driver goes to client.
6. Client enters cab.
7. Course starts.
8. Course finishes.
9. Client is purchased and driver is paid

And so on.

I can see there can be three aggregates: Client, Order and Driver. I want to split them into separate microservices. Do you think it's a good idea or I should start with one microservice?

I'm currently focused on the ordering a taxi. First of all I need to check if client doesn't already have a course assigned, later on I can create an order. After the order is created, I need to assign it to client. As during one request only one aggregate can be updated/created I wonder how to do it correctly. I've read something about Process Managers and I think it will be very useful in this case. I even draw a schema of communication. Can anyone tell me if my approach is correct and give me some tips on how to going further?

Process of creating an order

Answer 1

Someone said: "If you have more microservices than customers, you are doing it wrong".

And if you really follow CQRS/ES approach, resulting system is much easier to split apart than traditional ORM monolyths.

So focus on the domain first and start with monolyth.

Answer 2

start with the microservices design even in a wrong way, you get a better insight into desired architecture. because problems in microservices architecture design show themselves very soon.

• client and driver are both users of systems and have some commonalities so you can consider them as one domain and one micro-service for them.

• consider an order manager micro-service to assign client and driver to a trip by their ids. the order database may include trips table with two id keys for driver-Id and client-Id and some columns for the different states. after finishing each trip you can remove it from the trip table and insert that in an archive table. also, you can leave it there and partition your table daily to keep your database performance high.

• consider an accounting micro-service for keeping payments and transactions. It's ok if you opt to use NoSql databases for other microservices, but do use SQL database for your transactions.

• you may need another microservice for reporting and dashboards. mirror other dbs in a new one for reporting.

• you also need an API gateway to route requests to micro-services or do authentication

your process is a set of events. definitely, you will expand the system later on and perhaps will have some long-running tasks, better to have a message broker and implement your flow as an event/task flow using patterns like event sourcing.

Answer 3

I can see there can be three aggregates: Client, Order and Driver. I want to split them into separate microservices. Do you think it's a good idea or I should start with one microservice?

They all belong to the same bounded context. Bounded context translates nicely to microservices (see Eric Evans video: https://www.infoq.com/news/2015/06/dddx-microservices-boundaries). But don't start by designing a micro service, you are doing it in the wrong order. Design first your bounded context then if it makes sense create a micro service around the hexagonal architecture.

After the order is created, I need to assign it to client. As during one request only one aggregate can be updated/created I wonder how to do it correctly.

This is the perfect example of why you need to do it all in the same process.

But in the case you want to go multiple micro services, think of eventual consistency (https://en.wikipedia.org/wiki/Eventual_consistency) and create a message driven architecture between your services. Might be too much work in my opinion but for learning purpose can be a good idea.

Answer 4

Do you think it's a good idea or I should start with one microservice?

I refer you to the wisdom of John Gall

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Instead of worrying about microservices, give your attention to messages.