這是一個老問題，你可能以某種方式解決了這個困境，但我會盡力回答它。
您寫道：
「如從 帳戶界上下文ID，全名，電子郵件地址和頭像信息僅僅是在作業限界上下文相關的」
它們真的有關BC工作？使用實體（甚至更多：使用Aggregates），您正在建模進程，而不是數據。 Job BC的哪個流程或用例需要全名？在域名中是否有要求具有特定姓氏或名字的人不應被僱用？我不假設。通過這樣說，你可能已經記住了，你必須展示一些人物姓名顯示的屏幕。但屏幕不是進程，它們只是報告。您不應該通過報告/屏幕/ UI來驅動您的模型，而是通過特定域中存在的進程來驅動您的模型。
好吧，但如何做到這一點？顯然你仍然需要生成一些報告/屏幕。你不是嗎？答案是：您需要CQRS（https://martinfowler.com/bliki/CQRS.html）。命令堆棧只是聚集等達到的進程模型，所以你的構建塊會被一些ORM持久化。他們的數據模型將由他們（構建塊）的外觀如何驅動。在這裏使用一些ORM，可以很容易地堅持複雜的聚合，例如Hibernate。
然後，你必須建立查詢堆棧。我看到兩種實現方法，它們取決於兩個BC是否在同一個數據庫模式中。
當兩個BC位於同一個模式中時，只需使用一些數據庫視圖即可爲您的報告/屏幕構建數據。使用一些非常快速和靈活的複雜查詢ORM，例如MyBatis或Spring JDBC（如果您想要忍受JDBC憤怒，甚至可以使用普通JDBC））。如果你沒有被迫去使用Hibernate，不要在這裏使用Hibernate，因爲你會發現在這個堆棧中儘可能接近SQL是件好事。數據查詢抽象將迫使您與已使用的框架/ ORM進行鬥爭，以實現由Aggregates及其流程驅動的數據模型的複雜連接，而不是屏幕。另一個原因是，在普通的商業應用程序中，讀取數據比寫入數據庫多幾個數量級，在CQRS中講，查詢堆棧的用法比命令堆棧的用法多，因此您需要快速的操作。
當BC級在不同的模式，你需要生成報告數據庫（https://martinfowler.com/bliki/ReportingDatabase.html），將「合併」兩種模式。然後，您可以對合並的模式進行查看，並將問題簡化爲上述問題。
請注意，報告數據庫爲您提供了另一種可能性縮放：這個數據庫是隻讀的，所以它可以在多個服務器之間很容易被複制，您的查詢堆棧服務可以相乘，並且隱藏在一些負載均衡。
好，但與電子郵件地址屬性是什麼？您的域中可能有一個用例，應該通知僱主或申請人有關在域上完成的某些操作/過程。 我認爲，域名服務（或域事件處理函數）處理這種使用情況應該詢問其他BC的服務爲這個特定用戶的電子郵件（或廣播域事件將被處理的地方）。或者更好 - 它應該將這項工作委託給另一個BC省的一些Notification Service。此通知服務將詢問BC的帳戶服務的電子郵件地址。
在我看來界上下文（與通用語言一起）是DDD的最重要的思想。這是在建模過程中避免泥球的真正強大工具。它是真的不容易確定實際域:)
你的限界上下文共享同一個數據庫界上下文？理想情況下，他們不應該。如果他們這樣做，那麼你需要明確哪些BC擁有哪一部分數據，並且只允許擁有BC來更改該數據。 – plalx
我不明白你在說什麼。它是相同的應用程序，只是不同的有界上下文。我總是使用相同的數據庫，除非它有不同的應用程序。 –
BC通常被部署爲微服務並擁有自己的DB。 – plalx