0

I'm trying to apply DDD to a Golang service and sometimes I find that I have too many structs.

For example, I need to satisfy the requirements (for simplicity, I reduce the number of required fields):

  • Create user with name, email and password
  • Update user name
  • Tracking creation time and modification time on database

So if I want to have only the necessary fields for each operation and layer, my code seems like this:

Package user (the domain) with two files

user.go

package user

import "time"

type Repository interface {
    Create(u CreateUserInput)
    Update(u UpdateUserInput)
}

type CreateUserInput struct {
    Name             string
    Email            string
    Password         string
    CreationTime     time.Time
    ModificationTime time.Time
}

type UpdateUserInput struct {
    ID               string
    Name             string
    ModificationTime time.Time
}

service.go

package user

import "time"

type Service interface {
    Create(u CreateUserCmd)
    Update(u UpdateUserCmd)
}

type CreateUserCmd struct {
    Name     string
    Email    string
    Password string
}

type UpdateUserCmd struct {
    ID   string
    Name string
}

type service struct {
    rep Repository
}

func (s service) Create(u CreateUserCmd) {
    s.rep.Create(CreateUserInput{
        Name:             u.Name,
        Email:            u.Email,
        Password:         u.Password,
        CreationTime:     time.Now(),
        ModificationTime: time.Now(),
    })
}

func (s service) Update(u UpdateUserCmd) {
    s.rep.Update(UpdateUserInput{
        ID:               u.ID,
        Name:             u.Name,
        ModificationTime: time.Now(),
    })
}

As you can see I need 4 data structs for two operations. Is this the best approach in order to have safe and maintainable code?

Should I unify structs in repository layer (only one User struct with all fields)? In this case, repository implementer should to know which fields to persist in each operation.

  • 1
    DDD is not a coding methodology. – Robert Harvey Aug 14 at 16:34
  • I think that "too many structs" has nothing to do with DDD. You could have just one struct for all cases, and this would be more DDD-ish than what you propose. If we are talking about implementation, you should prefer the approach that most clearly expresses the business logic. – Alexey Aug 17 at 21:29
  • @RobertHarvey, though DDD is not a "coding" methodology, it does provide some advice on how to design and implement the model. – Alexey Aug 17 at 21:31
3

While it does seem like you have many structs floating around, these are necessary for a clear separation of concerns. You could skimp on some and directly pass around dictionaries and lists, but you would be losing some vital domain context.

The number of structs is only going to increase as your application grows over time and becomes complex. But that's what is needed - the separation of concerns - if you want to have a rock-solid domain design. In a good application model, each concept accurately represents itself and does not inadvertently get affected when another part of the system changes.

I would say ignore the problem of too many structs for now and treat them as domain-aware data structures. They are not maintenance-heavy and will help you over the long term.

  • Yes, I have simplified the problem statement. – Ruben Cervilla Aug 14 at 18:01
  • Ok, edited my answer to better focus on the primary question. – Subhash Bhushan Aug 14 at 18:09
1

Having a struct containing the input parameters for each method is going to mean a lot of typing.

I would simply pass the user around and not have the extra types. The code is shorter and does the same thing, you just shift the time.Now() down a level

I think it's good general advice not to create seperate types for this kind of object-with-meta-data thing if you can avoid it.

However! technically you're not any more coupled, you just have more classes. If you were doing an event driven design you might well want separate classes for different event types as they would be passed around various message queues and have an existence of their own.

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.