Domain Driven Design: Define boundaries from Domain Model

user_7267640 0
Viewed 160

I am working on a project and I am trying to utilize the concepts of Domain Driven Design.

I have the following domain model: (it is simplified for this question)

enter image description here

Let me explain the system first.

This system is for monitoring data coming from gateways. In this case there are two gateways, but there might be more in reality. Each gateway has its own implementation, so its own entities.

An example of the system is as follows:

A company has a project to monitor ship data.

So they have two gateways. A gateway with type Field-Device-Gateway and a gateway with type HTTP-Client-Gateway.

The first gateway (field-device-gateway) can have multiple field devices. A field device is a small device onboard on a ship. This device receives all data coming from devices on board of the ship. This is through a source (like an address) that has to be setup in the system.

The second gateway (http-client-gateway) can have multiple HTTP clients. Each client may have multiple routes.

So, a gateway also has variables. A variable is a configuration for getting a specific set of data. So, on the field-device-gateway might be a variable specifying to get integer data from a specific device, from a specific field device source, from a specific field device.

The system will make a request to the field device with the new variables. The field device then knows what data to send. It will be received by the system and stored in the database.

So, what am I asking?

Currently, everything is coupled. I need to define boundaries and then aggregates, but I just don't know where to start.

If I would not create boundaries, this will just become an enormous coupled mess and makes it hard to make aggregates.

So, what would the boundaries be? And what about the aggregates, are there even aggregates? Is everything its own aggregate?

And if everything is its own aggregate, how do I enforce some business logic like: A variable can only exist if there is a gateway, project and company.

domain-driven-design architecture
1 Answers

Before thinking about boundaries, you have to go back to domains and subdomains.

The problem space is your domains (and subdomains) and your solution space is your Bounded Contexts.

The first important issue in the application of the DDD in a project is to identify your sub-domains and in particular to divide them into the 3 following "families":

  • Core Domain
  • Supporting Subdomain
  • Generic Subdomain

This cutting is driven by this sub-domain families and by the domain expert.

A Bounded Context is a language boundary where context is king. We only know the meaning of a concept thanks to its context (which is also a cultural context).

How to avoid making mistakes in the division of Bounded Contexts?

  • When there are technical or architectural considerations
  • When you try to split a Bounded Context to distribute tasks to free developers
  • If you have two objects that don't have the same definitions, then they must be in two different Bounded Contexts

If you think to all this, you may easily separate your objects (your language) into these Bounded Contexts.

For your Aggregate's problem :

  • Try to decide for each class if it is an Entity or a Value Object (or Domain Service but try to avoid).
  • Your Aggregates are "some" of your main Entities which can drive other Entities
user_163312960
Related