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

Correct, I may have indeed obfuscated the term entity a bit here, I'm a pragmatist not a purist; to me an entity is a class with an identity and that is persisted "recognizable as the entity" in a database. I know that this last part is not official part of the definition, but in the end something has to be stored somewhere (and the definition of a database is very flexible). Of course ValueModels are persisted also, but they are almost always stored as part of an entity.

Say that there are two entities in two different BC, a debtor and a patient (we're talking healthcare here). In our migration process we need to take small steps, it's a running system after all, so we still persist both into the client table. In this way we try to reduce the class sizes and their interdependency by moving debtor logic to one BC, patient logic to the other. But there still is a lot they share; the actual persistence information, all kinds of validations that are common to both.

Tom


On 20-10-2014 22:51, Jose Fernandez [email protected] [domaindrivendesign] wrote:
> 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] <mailto:[email protected]> [domaindrivendesign] <[email protected] <mailto:[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 <http://en.wikipedia.org/wiki/Data,_context_and_interaction>
>> 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.
>>
>