Domain Driven Design and Hexagonal Architecture

Question

recently I was learning about DDD. I also have some experience with Hexagonal architectures(also know as ports and adapters). I want to put my leanings into practice and create a trading app. At first I wan't to have an monolithic application with some basic functionality. I have experience with combining DDD and micro-services plus ports and adapters and MVC but the challenges I'm currently facing are new to me.

So here are some functionality expected from the app:

• Monitoring and saving price/volume
• Executing automatic trades following strategies
• Back-testing an strategy
• Creating trade history and trading journals for traders

Of course there are some other things like authentication. Also services like database and web ui do exist.

So my first problem is what are the bounded context? what are the sub domains? For instance a users want's to see real time price data and under the hood, the application is saving this data in a persistent way regardless of whether the users is checking the prices or not! Now since two functionality share a lot, are they in a same bounded context or are they in a same subdomain?

The next problem I have is in packaging the application. After reading many articles is still couldn't get how I can I combine DDD with the Onion style of hexagonal. I'm using golang but I thing the overall structure should be the same cross languages. I came up with such a structure:

src
├─── cmd
│    └─── Main files
│    └─── DI files
├─── sub-domain1
├─── sub-domain2
│    ├─── domain model
│         └─── value objects
│         └─── entity objects        
│    ├─── application service
│    └─── infrastructure 
│         └─── ports
│         └─── adapters 
...

It is obvious that many thing are lacking here and I don't have any clue where to put things like repositories, DTO's, Event bus and many other objects. Also I'm not sure about this structuring since I have seen some implementations that nest the directories inside each other just like an onion! For now I don't want to have multiple modules and binary files but there is a possibility that the applications grows to multiple micro-services and if that happens I don't wan't to deal with heavy refactoring(May be it never happens but just as a real world practice I would like to think it might happen).

I'm very confused I some guiding can help me a lot. Thanks

Answer 1

First of all, if you start by a monolithic application, you can put all the features into one module but separate them in different packages (subdomain1, subdomain2). Starting with one module will permit you more simplicity. Then, if your application evoluate, and more people works on it, for multiple stakeholders, you can create microservices.

What are the bounded context? what are the sub domains?

Bounded contexts are the central pattern in DDD. See this article : https://martinfowler.com/bliki/BoundedContext.html

Your bounded contexts depends on your organization :

• how many groups, teams work on the application ?
• do they use the same language ?

If there are more than one team and these teams use different langages to talk about the organization (that your application manage), then you could create multiple sub domains.

Each subdomain is independant. You can have, for example, one Price entity in the first subdomain (Monitoring and saving price/volume) and another Price in the second subdomain (Executing automatic trades following strategies) with different fields. The fields and methods (features) of each entity will correspond to the language of each subdomain.

Now since two functionality share a lot, are they in a same bounded context or are they in a same subdomain?

Like I said previously, each subdomain can contains a Sale entity. In the article above, each subdomain contains Customer entity. But these entities could be different (fields and methods).

The next problem I have is in packaging the application.

The most important thing, is that your domain remains clean with well demarcated subdomains. And this domain must be independant and don't dependent on technical things.

After that, you can put all the technical stuffs in infrastructure.