Remove AddOrderItem method from Order class

[AndriiTokarskyi]

Remove AddOrderItem from Order's public interface since it is not its behaviour.

[dnfadmin]

All CLA requirements met.

[pavanarya]

@AndriiTokarskyi AndriiTokarskyi I have a quick question. I think we should interact with entities in a aggregate via Aggregateroot. In this case since Order is Aggregate, So I think it makes sense to have AddOrderItem in Order class. What are your thoughts?

[maranmaran]

@AndriiTokarskyi AndriiTokarskyi I have a quick question. I think we should interact with entities in a aggregate via Aggregateroot. In this case since Order is Aggregate, So I think it makes sense to have AddOrderItem in Order class. What are your thoughts?

Yes, I believe that's the point of DDD pattern showcase within Ordering service with complex domain entities encapsulating business knowledge, validation, and other domain-related responsibilities within its aggregate root.

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/net-core-microservice-domain-model

AddOrderItem encapsulated domain rules/logic for adding the OrderItem to the order and we would expose the items as read-only collections making them immutable and enforcing rules on each item added.

Within this PR as I see, the primary driver is the ability to propagate orders to ctor and allow it to add items on its own.
This feature can be done without removing the AddOrderItem from the public API.

However, I would still argue it's a poorer practice as we might want to return some validation results, etc success, errors whatever objects for each individual order item to asses it within our orchestration logic.

For resolving bulk orders I would much rather opt into implementing AddOrderItems instead of cramming these 'possibly expanded in future' essentials into ctor.

One more thing is that some items within this PR go out of the scope of the proposed change. (Some method renames etc)

[maranmaran]

If you wish to handle bulk complexity I would rather opt into implementing AddOrderItems instead of CTOR where you lose some flexibility like returning results, async, etc..

Reasons being AddOrderItem can/could change from void to some functional object, validation, error result with some success flag for instance since it should encapsulate some logic which currently is not there but this is still a showcase of the pattern.

[maranmaran]

Rename is out of proposed scope of this PR