adnanioricce / dhsys Goto Github PK

I think this will be the most painful part of the project, wpf is not very friendly with CI and CD processes. CI/CD will be necessary if I want that the software updates don't break everything and that I can deliver something without too much pain.

There is currently a Payment entity type that can be created with Payment method, that handles the operations related to payments, in such a way that different handlers for the payment could be defined, mainly to handle dependency with external services like payment gateways, trying to avoid coupling in this part.

Besides that, the solution seem to be over engineered, but this I want to address in another issue( #16 ).

Recently, I decided to limit all the Remote and Local syncronization to a different Web Api (Api.Windows), so now I am only using the LocalContext, but the migrations methods that I define will try to find the Migrations of the wrong context.

The payments operations are planned to be handled by the following constructs:

• entities Payment,PaymentMethod(payment method info and behavior),PaymentMethods(enum with the allowed payment methods)
• and the related services IPaymentMethodService and IPaymentProcessor

the names don't seem obvious so I will explain

• Payment represent the Intent of a customer to pay for something, with a certain amount on a certain method
• PaymentMethod represent the The process and rules that are performed to handle a payment
• PaymentMethods(need better name) represent the set of payment methods allowed
• IPaymentMethodService represent the set of operations that connect the domain context and the external concerns
• IPaymentProcessor represent the the translation of a set of operations of a payment provider to the domain context, a abstraction of the API of a payment provider(eg: PayPal, Stripe...)

the first thing to notice is that the IPaymentMethodService have a purpose of mediator in the system, but this don't seem to be necessary, this is the code of the InHandsPaymentService to issue payments

protected readonly IPaymentProcessor _processor;
public async Task<PaymentResult> IssuePaymentAsync(Payment payment)
{
    var result = await _processor.ProcessAsync(new PaymentRequest(payment));
    _paymentRepository.Add(payment);
    await _paymentRepository.SaveChangesAsync();
    return result;
}

and the method ProcessAsync of InHandsProcessor

 public Task<PaymentResult> ProcessAsync(IPaymentRequest request)
 {
     return request.SendAsync();
 }

the PaymentRequest object has a class that implements the interface IPaymentRequest, in this implementation, it receives a payment and has a method ```SendAsync``, that evaluates if it should be considered, paid, partially paid and so on.

public async Task<PaymentResult> SendAsync()
{                        
    await Task.Delay(0);//yes, this shouldn't happen
    return PaymentResult.Create(Payment);
}

there is also a coupling with other parts that I think that actually aren't necessary, and will probably be a source of issues. This is a entity on the system, so it's persisted on database, so it will need more work to handle conversion from domain to DB and vice versa

public class CreditCard : PaymentMethod
    {
        protected readonly IPaymentProcessor _paymentProcessor;
        protected CreditCard()
        {

        }
        public CreditCard(IPaymentProcessor paymentProcessor)
        {
            _paymentProcessor = paymentProcessor;
            Name = "CreditCard";            
        }        
    }

The solution that I think till now, is to remove the need for the IPaymentMethodService, and handle the abstraction and mediation between the payment provider and domain context with the IPaymentRequest and IPaymentProcessor only, using the IPaymentRequest to represent the operations of the payment provider and wire things with IPaymentProcessor and PaymentMethod. Make all this decoupled should be kept in mind

Currently there is no data to make simple demonstrations on the application.
For now, thinking in add a procedure to seed the application with some data for demo with the Migrator console App(at the momento, just on the development branch).
This will probably take some time

For now the Core library don't provide any restriction or guideline on how to use it or interact with the domain model
instead of using the entities this way:

var product = new Product {
    Name = "Generic Cosmetic Product",
    ProductPrices = new List<ProductPrice>{
       	new ProductPrice {
            EndCustomerValue = 12.99m,
            CostPrice = 10.99m
        }
    },
    ProductCategory = new List<ProductCategory>{
        new ProductCategory{
            Category = new Category {
                Name = "Cosmetics",
                Description = "Cosmetic Products"
            }
        }
    }
}

would be better use them in a more specific way like this:

var product = new Product();
product.AddToCategory(Category.Create("Cosmetics","Cosmetic Products"));
product.SetNewPrice(endCustomerValue:12.99m,costPrice:10.99m);
//restrict unexpected use from api caller
product.ProductPrices[0].EndCustomerValue = 0.0m; //compile error

if I combine this with some unit tests I can provide some usable API for anyone who come back here(probably me after some months).

it's common to have to manage the amount that gets in and out of this kind of business, to know how much you spend and earn, how much change is still remaining and probably will need, and so on. Because of this, would be useful to add a transaction entity, that keeps track of this kind of data flowing in the business.
it would be needed to keep track of the amount of cash available, and validate operations that impact it, a payment may be cancelled, if there is no change to return to the user, or no change at all, in the case of accept payment later.
Maybe, a way to keep track of the notes is also important, but this problem would be a different problem from a transaction entity, despite related.

The project get bigger and bigger and still there is no way to use it.
Need to define some basic goals and have at least one feature working.