2

I'm quite new in the DDD-World and I'm just trying to figure out all the basics so please bear with me!

I have the following Entities: - Datamodel - Object Types - Object Fields

A datamodel can contain 1..* object types and each object type has a unique name and can contain 1..* object fields. A field has a certain type which is either string, int, date OR it is an relational type:

type User {
  name: String
  age: Int
  articles: Article
}

type Article {
  name: String
  author: User
}

Now I have the folowing use cases:

  • Add a object-type to the datamodel
  • Remove a object-type from the datamodel
  • Add the object-field to the object-type
  • Remove the object-field from the content-type

As far as I understood, all of my entities build the aggregate and the Datamodel entity is the root entity, is that correct?

I came along with the following implementation approach:

The Datamodel entity has the ability to add object-types and holds a list of object-types:

public class Datamodel {
    private final List<ObjectType> objectTypes = new ArrayList<>();

    public void addObjectType(String name) {
        ObjectType objectType = new ObjectType(name);
        this.objectTypes.add(objectType);
    }
}

The Object-Type entity has the ability to add object-fields and holds a list of object-fields.

public class ObjectType {
  private final String name;
  private final List<Field> fields = new ArrayList<>();

  public ObjectType(String name) {
    this.name = name;
  }

  public void addField(Field field) {
    fields.add(Objects.requireNonNull(field));
  }
}

If I now want to add a relational field to my object type, I need to ensure, that the datamodel contains an object type with the respective name, thus I need access to the list of object types within the datamodel entity. How would I model this scenario?

Is that approach correct or should the Datamodel entity be responsible for adding both object-types and object-fields?

  • What domain are you modelling? Classes with names like Datamodel and ObjectType are not very 'DDD-like'. Have you read about the ubiquitous language? – Rik D Jan 31 at 8:34
  • The application is something like an API-Creator. The user has the ability to create multiple api's and each api has exactly one datamodel. – w0wka91 Jan 31 at 8:45
  • that is basically a pseudo programming language DDD doesn't really apply – Ewan Jan 31 at 12:01
  • it's right that it is quite abstract but the end user is always a developer. Why doesn't DDD apply? – w0wka91 Jan 31 at 12:27
  • As far as I know every major RDBMS already implements the exact features you are seeking to model (along with oodles of useful related features). Do you see what I'm getting at here? – king-side-slide Jan 31 at 18:06
0

You shouldn't start with the "data". I assume here (because of Java) you want to use object-orientation.

You should start with the behavior. Adding a field to a type is almost a behavior in your case, but not quite. I would start with the main use-case: why would this application be useful? What is its purpose? Start always with the most important things.

For example, if you want to generate WSDL at the end (that's why the user is using your application), then start with Datamodel.generateWsdl(). Continue with decomposition. You would have ObjectType. How could that contribute to generateWsdl(), maybe by ObjectType.generateXmlSchema(), or whatever.

At the end of this modeling, you still have no "data" anywhere, but you already can "read" all your use-cases, just by looking at the classes/interfaces and methods (Ubiquitous Language).

Then you just put all the data that is necessary to fulfill those behaviors in the relevant objects. They will almost always naturally belong somewhere.

Now this is perhaps not as easy as I just made it out to be :) But the more exactly you can describe your functionality the easier it is to use/maintain/extend your application.

  • First of all, thank you for pointing me in the right direction. Yes, you're right. I want to use object-orientation! The main use case of the Datamodel is the generation of SDL. Therefore its using the specified object types and fields. Instead of creating the generateSDL() method, I would have used the toString method to generate the SDL. Which implementation difference makes it when I use your approach? What exactly do you mean by adding a field to a type is almost behaviour, but not quite? – w0wka91 Jan 31 at 12:46
  • As far as I understand, the user does not really "add a field to a type". The user will write some DSL, and you will parse/compile that to some intermediate domain representation. So there is no use-case to add a field, or rather, that is covered by writing the DSL differently. – Robert Bräutigam Jan 31 at 14:48
  • The user is able to create different API-services. As soon as he created an API-Service, he is able to add content types/content-type-fields to his API. Example use-case, the user wants to manage books in his API: 1. User creates the content type Book 2. User adds the content-type-field name 3. The user adds the content-type-field author – w0wka91 Jan 31 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.