2

Well, it depends on where you draw the "boundaries" of your Domain and how flexible you want to be with respect to serving various use cases. In any case, the fact that the objects share their lifetimes does not necessarily mean they are better aggregated together. It looks like your CustomerSettings object is not really a Domain-related entity, in the ...


1

If two BC want to save some data into different collection. It may be some consistency problem. Do somebody know how to resolve this problem? The usual solution is to stop expecting that the two copies of the data will always be consistent. Instead, we pay more attention to authority (who controls the "real" data?), and caching (how old is this copy?). ...


1

Normally (I mean barring further requirements which may conflict) I would go for Option #1. Here is why in short: The REST API and the "model" are naturally coupled. If you try to separate the two you will end up changing both most of the time. New model feature? Redesign/Refactor model objects? Different supported workflow through the model? For any of ...


1

Well, well, let's get something that is bothering me out of the way first... if (Company == 1) { //This is how code should NEVER look like } OK, now that I took it out of me it, let's get to the point! Short Answer The short answer to your question is yes, it does make sense to make entities depend on abstractions in some occasions. Once you ...


Only top voted, non community-wiki answers of a minimum length are eligible