So, a BC takes DTOs or commands as input then publishes events as output. That's the approach I've taken with the Invoicing component (so that it wouldn't know about anything Subscription). If you really want to keep things decoupled, because you want a reusable component, then you can use a mediator that will listen to one BC then send the relevant data to the other one. So we have our BC listening to other BC's events. Those are DTOs and contain all the relevant (in/out)data for an use case. In a message driven app, this means you send commands to be handled and you get events. You don't see what's inside, you know only about input and output. What about the data that a BC might need from another? A BC should be like a black box. But that's just a coincidence, and in fairness, if a BC shares a lot of concept and definitions with another, perhaps they should be merged. Of course, some concepts may be generic enough that their definitions will be identical. But the VO are a different story and each BC really has their own definitions. ![]() However, in practice, a concept which is an entity in other BC will at least be defined as an id in other BCs. So the Account is not just an id because the Membership Account entity has a property Id, but because the other component said so. An Account is a fully defined concept in Membership but it's just an id in Subscription, Invoicing or any other BC and that's because the BC itself controls the definition. How do we solve this, without coupling the components (breaking the boundaries)?Įach BC has its very own definitions of concepts even id it happens that they share the same name. Similarly, Invoicing is related to an account and needs data usually found in Subscription. But, a subscription is related to an account so it might seem that Subscription must know about Membership model. The components being autonomous, they don't depend one on another (at most they know about other's abstractions) so they don't share the model i.e the model of one BC doesn't cross its boundaries to be available in other BC. Each is like a mini app in itself, each has their own domain and thus their own model which makes sense only for that component (BC). For example, I'm working on a Saas app and these are some of the components: Membership, Subscription, Invoicing, Api Server, Api Processor. If you're designing your app as a group of autonomous components (and you should) aka vertical slices aka microservices (for distributed apps) working together, then each component is a BC. First of all let's remember that a BC simply defines a model that is valid (makes sense) only in that BC. Bounded Context (BC)įirst thing before starting an app is to identify the Bounded Contexts. Only an object representing a Domain concept can be classified as an Entity (it has an id) or a VO (it encapsulates a simple or composite value). You can have simple objects in your Domain and you can have objects which have a business meaning. ![]() Let me be clear about one thing concerning Domain objects: they aren't either Entities or Value Objects (VO).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |