bounded-contexts

I'm developing a solution by multiple maven modules to handle different bounded contexts. Thanks to spring boot each module exposes own rest api and all of them hosted in one maven module with a class that annotated by @SpringBootApplication. The simplified project structure is looks like this: parent |-- pom.xml |-- ... |-- host |-- Application.java |-- resources |-- index.html |-- driver |-- api |-- resources |-- register.html |-- notify |-- ... |-- passenger |-- ... I've tried to use the same pattern when facing with the composite UI: one place that keeps layouts, static resources and in

I'm breaking my system into (at least) two bounded-contexts: study-design and survey-planning. There's a concept named "subject" (potential subject for interviewing) in the study-design context. We also maintain associations between subjects and populations in that domain. Now, in the survey-planning, we also need (some) information about the subject (for example: for planning a visit, or even for anticipated selection of questionnaire, in case the population the subject belongs to is known beforehand). So, I need that "subject" in both contexts. What approach should I pick? Having a shared

I've started learning the principles of DDD and I'm currently trying to get a grasp of the concept of a bounded context. In particular, how do you decide just how big (or small) it has to be? Yeah, I know, as small as possible and as big as necessary (according to Vaughn Vernon). Let's say I were to model a blog. I could then go and say there are 3 bounded contexts involved: 1) Front Page (featuring the most recent articles, no comments shown) 2) Discussion (a single article including comments) 3) Article Composer (where I compose an article). However, this doesn't feel right (the ubiquitous

I am trying to understand how entities operate in multiple bounded contexts. Given an Employee of a Company. In (for example) the Human Resources context, this person has a name, surname, address, salary reference number, and bank account. But in the Accounting context all that is relevant is the salary reference number and bank account. Do you have an Employee entity in the HR context and a Value-Type (e.g. SalariedEmployee ) in the Accounting context? class Employee { public BankAccount BankAcountDetails { get; set; } public string FullName { get; set; } public Address ResidentialAddress {

I am trying to store domain events in a postgres database. I am not sure in many things, and I don't want to redesign this structure later, so I am seeking for guidance from people who have experience with event sourcing. I have currently the following table: domain events version - or event id, integer sequence, helps to maintain order by replays type - event type, probably classname with namespace aggregate - aggregate id, probably random string for each aggregate timestamp - when the event occured promoter - the promoter of the event, probably user id details - json encoded data about the

I have setup a domain project which is being populated with an ORM. The domain contains of different aggregates each with its own root object. My question is how properties that cross the aggregate boundries should be treated? Should these properties simply ignore the boundries so that a domain object in bounded context A has a reference to an object in context B? Or, should there be no direct link from context A to B and does the object in context A have an "int ContextBId" property that can be used to get the domain object from B through the B aggregate root? Or ... An example: Context A =