On which layer should I create constants in my application with DDD concept?

Asked

Viewed 272 times

2

I’m using the DDD concept (Layers: Presentation, Application, Domain, Data and Crosscutting) in my ASP.NET Core MVC application and I was wondering about the best place to create my constants.

In my Domain created a class ContatoTipo (Id, Descricao) which will contain the data (LANDLINE, HOME PHONE, MOBILE PHONE, etc). I will need to create constants for such data, to be used in the other layers to be able to validate, etc. Should they be created in the Domain layer? Must be created in the same class model ContatoTipo? I’m afraid to expose mine too much Domain.

  • What kind of accountants?

  • Int type to represent Id and string for Description. I have several similar classes that I will need to do the same... ;)

  • I’ll answer, but unless you’re saying something wrong, you don’t need a constant.

  • Shows an example of a class that implements this relationship with the Contactotype class...

  • For example, imagine that in my view I needed to do an if to validate if the contact == landline (Id = 1). Imagine that someday, I need to change the value of the landline id from 1 to 50... It is tense that I go looking in the entire project, where are the validations and change everything to 50.... It does not seem productive to me....

  • @Maniero, I believe he must be getting confused with Enums, but without seeing the modeling gets difficult, since the Phone could be a Telephone VO.

  • In vdd, I created a table in the database (Contactotype) and a class (Contactotype) that will be used exclusively by the system... the User will not be able to change. In this case, I’m not creating an enumerator (It would be easier, but I needed to save more information, so I wouldn’t be able to)..

  • But the validation of the domain is necessarily in the domain (or some other layer that is directly related in the domain). I see no point in having to change in N places if X was 1 to 50, until it was 1 and went to 50, as the previous records? will you update everything? It doesn’t make sense yet. I believe there is a problem of abstraction of the problem. I would create the Enums in Dominio and would not depend on an Int type to determine the type of phone, since being 1 or 50, the phone is Fixed.

  • Possible duplicate of MVC DDD Project

Show 4 more comments

1 answer

1


First make some considerations: Constant is really useful? and What is the difference between const and readonly? (the most important is the philosophy of use of each).

Just as variables constants should be declared as close to where they are used or at least in place that makes sense.

I’m no expert on D.O.D., but I’ve never seen anything in this class talk about it. I imagine they understand that it’s your decision and that you’ll have good sense to put it in the right place, like the other artifacts. DDD and other techniques that people adopt that they think will improve the code doesn’t help the way they think, what makes the code look good is deep knowledge, commitment to quality and common sense. You kind of don’t teach these things, you get formed like this.

Put in the domain or somewhere else

If the constant is important for the domain then it is there that it should put, if it is more general it should put in a layer that communicates with the others, if it is in the presentation that is used then it is there that it should put. If you have a hard time knowing where to put it then the problem isn’t that you don’t know where to put the constant but you do know where to put anything, and you’re probably already putting it in the wrong places and it doesn’t matter much anymore, After all if everything is wrong you should leave it and do it in a way that you can understand and do right.

I don’t see much difference between the constant and the rest of the data structure. And I don’t know if I should create a constant for the problem, the question needs to be very well defined to know. If you don’t have to have that constant then all the places are wrong. The comment says it doesn’t even need constant.

If it’s a default value you use for something then it might even be a constant (but I think it’s just an immutable datum and not a fact constant, if you use this mechanism you may even have problems in some way compiling), and it must be there, default value is part of the domain, it is not part of the object, but a static value is still part of the domain.

It may be that someone says something that the DDD should not have static values, if this is true it may be good or bad. It might be good because it may require a different mechanism to give it more flexibility, but keeping it in another class makes it difficult for me to understand and even legible the code, you have to remember the existence of this other class.

On the other hand new comments above speak of something else that may be that this is something else and should be just another domain and not constant. It can be an auxiliary domain to use in the main domain. You don’t have enough clear information to nail (and it’s not easy to put everything you need into a question). This would be interesting because it would give flexibility. In a certain way it would use one of the mechanisms of the data dictionary (see below) :)

It wasn’t clear if it should be a constant, but DDD usually uses attributes with literals (which are nameless constants) so it can be right, so it makes code less flexible and harder to maintain, what I consider a failure of DDD and other techniques preaching the same.

I prefer data dictionary to give flexibility and facilitate maintenance much more than DDD (interestingly it can be dynamic which would give the same acronym :) ).

Completion

I’m a critic that a technique that picked up fashion became famous but is full of flaws. People use it for the fame and ignorance of other techniques and not for the quality of it.

But if the whole methodology is already inadequate, you can’t put it all away without abandoning it.

Note that the text practically says you need to put in the domain to use in the other layers. To me this is answered, it is not clearly written the domain, but if the text was written correctly you can infer this.

  • 1

    Thank you for improving my reasoning @Maniero. I believe that, in my case at least, it is appropriate to create in the domain layer. Even, there are already other constants separated in a folder... I will try to follow this same reasoning. Thank you again! :)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.