Writing cleaner code with Domain Driven Design by Paul van der Slot 

Good question. I would say an employee originates from one context. Maybe the HR context where a candidate becomes an employee after signing a contract. After that an event could be fired like 'Employee hired'. Other contexts could listen to that and use the same Employee id(as a reference) to create a consultant for instance in the sales context. If you want to have an overview of everything related to that employee you could group information of different bounded contexts, using the shared employee id.

@@paulvfc I like that answer it makes sense there would be one authoritative demand that others could key off of and I also like the thought about using Events the other domains can listen to if they want to do something about their version of employee

my 2 cents. An "employee" does not really exist "across" bounded contexts. If it does, is mostly by mistake or by some misfortunate language representation. So in the example with "employee" and "consultant", it becomes obvious that there has to be some aggregation of "pieces" ("employee", "consultant") which lives outside of these bounded contexts and (forcefully) puts the pieces together. Often these are just "reports", and since they are rather technical than business, not sure makes much sense to think of them as "bounded contexts" (maybe as support business context). As some others commented, there should be another talk (Paul? ;) ) reg. communication and translations (or not) between bounded contexts.

Indeed Thomas, there are always tradeoffs. I would recommend agains using wrappers for everything. Some Strings that need validation and have some business logic are perfect cases in my opinion. Think about an IBAN (validated), and which you might ask the country code (substring). But wrapping a firstName in another object is not something I do. No validation needed, no extra logic, just code bloat.

@@paulvfc I understand your point. Given a typical OO language like Java it is a reasonable approach. Other languages offer different possibilities for the example you describe. For instance what I typically do: leave the email-address as a string, but instrument functions (at the contextual boundaries or where-ever you like) with spec validation that can be turned on/off using a flag, depending on the deployment env. This approach doesn't seem like a big improvement at first sight but *dramatically* simplifies nested data-structures that pass through domain functions. Plus the significant advantage that I can use whatever functions my language offers to manipulate Lists, Maps, Vectors, Strings and other primitive scalars to manipulate the data structures while they pass through my domain functions, leading to much less code. The shape and type of these structures are spec'ed in the appropriate time and place, enabling a leaner approach and more opportunities for generic function design because there are no "private domain language" classes to take into account. Check out Rich Hickey's talks for a more elaborate perspective on this matter.

Domain Driven Design is agnostic to a programming paradigm. It’s more of a design approach I believe. To take your problems and solution from the Enterprise world to software world. However, Object Oriented Design aligns with arguably all of its construct.

I think there’s a deliberate reason cause if someone think they already know encapsulation and you tell them to always favour it in domain driven design, it can mean different thing to different people.

@@khajalieubarrie5088 That... is so meta. The ubiquitous language of programming itself.

for me this phrasing represents "intentional" encapsulation. usually when you're taught about encapsulation you're only taught about getters and setters. the concept of "tell don't ask" goes further

It depends how you perceive those terms. For example when you're using Doctrine/Hibernate library in infrastructure on the side of repositories, there's always some validation and transformation into domain objects. Or for example we are checking tenant id in multi-tenant application for each received object even it's already handled by database itself. Just to be sure/to double-check that we're not receiving what we shouldn't receive.

Agreed. The repository has a dependency on DTOs such as Card, which is weird. Secondly, sometimes the validation depends on other entities. A single repository can't validation and transformation alone.