Re: Large domain, small team: how many contexts?

I think they are calling an entity a class that is one to one tied to a table in a database. These are two totally different things. For example, you can have the entity Client in two Bounded Contexts. Depending on what ORM you're using, you can map the two Client entities to the same table in your database. From a domain perspective, they are two different things. From a persistence perspective they may share the same data. 

In plain English. 

customer service bounded context -> client (Id, zodiac sign, name). 

accounting bounded context -> client (id, name, SSN, payroll type)

These are two different client classes. Your ORM will map them to the same Client table. 

Get the idea? I know EF6 has what they call DbContext. You can basically have one DbContext per Bounded Context.

Got it?

Sent from my iPhone

> On Oct 20, 2014, at 12:20 PM, [email protected] [domaindrivendesign] <[email protected]> wrote:
> 
> Hi Tom,
> 
> 
> "duplicate entities" does not sound welll... There are of course many definitions for what an Entity is, one is "A thing with distinct and independent existence", another is "An object that is not defined by its attributes, but rather by a thread of continuity and its identity". In our software-world an entity is a representation of a real-world thing with a very specific characteristic: given its id, you can point it out and there cannot be any doubt which instance is addressed by this id. In DDD, a certain entity can appear in different forms (views) in different Bounded Contexts but in the end, all of these point to the same thing. The different views will very likely have a common base-set of attributes. This pleads for a common model to handle the base-views entities. Extending these classes in the various BC's is a way of implementing, interesting thougths are in the DCI (Data, Context & Interaction) vision: Data, context and interaction - Wikipedia, the free encyclopedia
> In DCI, behaviour is captured in roles. Entities may implement various roles, roles will have a more strict binding to specific BC's than the entities themselves. E.g. a Person entity will appear in many BC's, but as an Employee in the HRM BC, as a user in the System BC, as a plannable resource in the Planning BC etc.
> 
> Best, Rob.
>  
> 
>  
>