0

I had an architecture question about how to manage objects with different properties based on the services they are in. Is it okay to have an object defined in to different places with similar attributes but different scope based on the service.

As an example, a car has many parts. You might make a service that returns Car objects that them different attributes (Maker, Model, Parts, Color, etc).

Another service is made that returns Parts and attributes (Maker, Material, Appropriate Cars, etc.)

I understand that creating a Car Object with a list of Parts and a Parts object with a list of Cars will just cause the thing to blow up, I figure that there must be a better way to define the link.

For Car would a CarPart object with just information relevant to the part without the list of cars work? Same with a ApplyableCar object for the Parts object?

Any suggestions are helpful

|improve this question
  • Depends. You have to think deeply about your domain (investigate it further, by talking to people who operate in it, and follow code change patterns over time). If the concepts within your two services are only superficially similar, but have subtly different meanings and evolve independently, then it's OK and desirable to define the "same" concept in two places (and this can be applied on different scales - class level, or bounded context.level in DDD). In BC case, you do references via some sort of ID. As for Car/CarParts - base the decision on what your domain logic needs to achieve. – Filip Milovanović Feb 21 '19 at 8:20
  • Yea I think i didn't fully understand how I should manage object scopes within a domain. After thinking about it for a bit, I realized that they are different domains and that they don't need to have a full reference to each other at that moment. Thanks! – FDaniels Feb 21 '19 at 18:48
2

It seems you are trying to define objects based on what data they have inside. This is not an object-oriented design process, therefore it will most likely not work in this context.

You have to think about two things:

  1. Whether the object is something business-people familiar with your domain would understand.
  2. What behavior (i.e. methods) those objects need to exhibit, again, that business people would understand.

These properties should hold for all objects in your project.

To your first question, it might be the case that the same concept ("Car" for example) might have different behavior (means different methods, different class) in different parts of an application. It usually happens when multiple business units try to collaborate in a project, it is however unlikely in smaller applications.

|improve this answer
  • I thought about this for a while and I think I understand now. In the example, if we define Car as the main domain of the object, then getting cars that a part would fit could be part of the car service that returns the corresponding car objects based off a part ID rather than an object with a list of "ApplyableCars". Thanks! – FDaniels Feb 21 '19 at 18:43

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.