Domain Modeling - Payment Methods

Asked

Viewed 627 times

6

I am modeling the sales part of my system and came across the following situation. I created a register of payment methods and payment method MONEY is standard and cannot be changed, deleted, etc. I use this form of payment in cash opening for example. I create this form of payment in the installation of the application.

The system allows the user to create new forms of payment according to the need. These new forms of payment may be amended.

How I should treat this situation?

I must add a property in the Formapayment class that enables the class to be deleted and changed?

class FormaPagamento {
   private Boolean podeSerAlterado;
}

I must make a check whenever an operation is done and if it is MONEY prohibit the operation?

Should I remove the options to change any form of payment and just allow new forms of payment to be created? Having the option to enable and disable payment methods.

class FormaPagamento {
   private Boolean ativo;
}

[ EDITED ]

This is my class diagram for payment methods.

inserir a descrição da imagem aqui
When the user registers the form of payment I display the options for him to register which payment conditions he wants to make available, type 2 x no interest on VISA card would be a condition with 2 installments, 30 days of recurrence and first installment in 30 days.

In the case of the form of payment MONEY i have a default condition that is On Demand, however the user may want to register a new condition for payment on MONEY. So I kept this form of payment in the register and not hardcoded.

software-architecture modeling ddd
  • 1

    I don’t know if it should be a matter of knowing the form of payment itself whether it can be changed or not. I believe that the creation of a service responsible for carrying out the modification of forms of payment would be a more uncoupled way of resolving this. This service would check which form of payment is being modified and would fail if it were a form that should not be modified. This could be a hardcoded rule in your application.

  • It is an alternative. I had not considered this option, but in case I can only perform this work in the service if I consider it a rule of the application and not the correct domain?

  • 1

    Good placement; in a way this knowledge is part of the domain itself and perhaps removing this responsibility from it can create problems in how interactions with the domain happen. I confess that I do not know exactly what pattern the practices of DDD advocate in this case, but I will do a research because I found an interesting problem.

  • Yes it is an interesting problem and even occurs in other parts of the system, in case some accounts of the plan of accounts also can not be changed. But this is only a problem because I refer to such objects by description. In the case of the payment method MONEY, I search the repository for the repository description.

  • 1

    Not everything in life is a register. There are types of entities that exist only in the code and not in the database. If the business rule is trivial, leave the register at the bank and do not worry about preventing the customer from deleting "money" - it is only him to register again. If the system is more complex, each form of payment has unique behaviors and relationships that cannot be defined only by its attributes in the bank, in these cases the entity is hard coded and is not registered in the bank (eventually some of its attributes are registered, but not the entity itself).

1 answer

1

I wanted to comment instead of answering, but I still do not have enough points for such. Sorry.

Looking from the point of view only of Object Orientation, the problem seems to me to be a simple case of inheritance. Cash, Check, Card, Boleto, etc., are specializations of Meiopagamento class.

I don’t quite understand what you mean by "creating a form of payment". I do not know your business and I may be mistaken, but from my limited optics it seems to me that there are a small number of possibilities for possible forms of payment, so I can not see sense in delegating to the user the registration of these objects.

I agree with Fuad when he says, "I don’t know if it should be knowledge of the form of payment itself that it can be changed or not." The key point is to discern when the rule is in business and when the rule is in business. If Voce is dealing with petreas rules (for example, Cpfs are composed only by digits), then it makes sense that the object itself knows the rule, otherwise it should be transparent to the object.

Thinking about implementation, the Pattern Strategy design seems to me a good proposition to solve this problem in an elegant way. I think it’s worth considering the case.

  • My reasoning was as follows. There may be various means of payment credit card, debit card, etc. But there may be credit card Mastercard, food ticket, paypal, pagseguro. So I left it up to the user. Now looking from another perspective it may be that there are categories of means of payment that would be Money, Credit card, Debit Card, Boleto, Transferência Eletrônica, Cheque. And payment methods of the credit card category would be Visa, Mastercard, American Express. Maybe it can be looked at that way.

  • I am developing an ERP for micro and small businesses.

Browser other questions tagged software-architecture modeling ddd

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