Domain Modeling - Forms of payment

Navigation
6

I'm modeling the sales part of my system and I came across the following situation. I have created a payment method record and the MONEY payment method is standard and can not be changed, deleted, etc. I use this form of payment in opening cash for example. I create this form of payment in the application installation.

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

How should I treat this situation?

Should I add a property in the class FormPaying that enables the class to be deleted and changed? 

class FormaPagamento {
   private Boolean podeSerAlterado;
}

Should I make a check whenever an operation is performed and if it is MONEY prohibit the operation?

Should I remove the options for changing any form of payment and only allow new forms of payment to be created? Having the option to enable and disable forms of payment. 

class FormaPagamento {
   private Boolean ativo;
}

[EDITED]

This is my class diagram for forms of payment.


When the user registers the payment method I display the options so that he can indicate the payment conditions he wants to make available, type 2 x interest in the VISA card would be a condition with 2 installments, 30 days recurrence and first installment in 30 days.

In the case of the MONEY payment method I have a default condition that is Vista, but the user may want to register a new payment condition in MONEY . So I kept this form of payment in the registry and not hardcoded.

    
asked by anonymous 30.04.2015 / 18:50

1 answer

1

I wanted to comment rather than reply, but I do not have enough points for that yet. Sorry.

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

I do not quite understand what you're saying by "creating a form of payment." I know your business and can be wrong, but from my limited otica seems to me that there are a small number of options for possible forms of payment, so I see no sense in delegating to the User registration of these objects.

I agree with Fuad when he says "I do not know if I should be aware of own payment the fact that it can be changed or not." The key point is to discern when the rule is business and when the rule is petrea. If you are dealing with immutable rules (eg, SSNs are composed only of digits), then it makes sense that the own object Meet the rule, otherwise it should be transparent to the object.

Thinking about implementation, design pattern Strategy seems to me a good proposition to solve this problem elegantly. I think it's worth evaluating.

    
01.05.2015 / 14:27
How to copy a repeater on the same page Targeting all traffic from root to sub folder results in error "403 forbidden" if it does not have "index.php"