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

Be careful. As you describe it, I don't think that each law should be a BC. More like a disguised Strategy Pattern material here. Your laws sound more like "business rules". You need to be careful when you're modeling your domain. Many times we make the mistake to try to emulate real world in our domain because we are trying to stay truthful to the ubiquitous language and this confuses us. It's not about emulating it, but to solve a problem that real world creates. 

In the other hand, I don't think there's  anything wrong with naming "patient" a "debtor". But at the same time, in my experience, the Bounded Contexts give the right meaning to "patient" with no need to rename it to "debtor". Unless that's the term used by the collection department. Then it makes sense. 


Sent from my iPhone

> On Oct 21, 2014, at 1:29 AM, Tom Eugelink [email protected] [domaindrivendesign] <[email protected]> wrote:
> 
> Another interesting aspect is that the role of patient can be played in multiple BCs. As of the first of januar 2015 our government will change a lot of laws named HLZ, WMO, JW, ... Of course each law has its rules and conditions, so each law will be implemented as its own BC and each patient will have logic specific for that law. But they all still are a patient, with possible connections to all kind of other data which is required to actually implement the law; in the end any of these laws can result in "care" being given to the patient. So each domain has to know the concept of a patient and concepts involving care in order to decide which of the law's finesses are applicable. I prefer not to reimplement "patient" and "care" in each domain.
> 
> Tom
> 
>> On 21-10-2014 07:18, Tom Eugelink [email protected] [domaindrivendesign] wrote:
>>  
>> 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] [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.
> 
>