Guidelines to decide when a domain role needs to be explicitly modelled

I looking for some guidelines as to when one must explicitly model a role in the domain model.

I will explain my current stance with the help of an example here.

Say we are building a health care system, and the business requirement states

"That only doctors with 3+ years of experience and certain qualifications can perform surgeries"

In this case it is evident that the act of doing a surgery can only be performed by a person playing the role of a doctor and the doctor needs to meet certain prerequisites to perform the action


So basically all doctors are not the say

This method will probably check if the preconditions are met, else i might use a specification object.

So in the above cases, I will model the role explicitly.

Now lets consider the alternate scenario.

Only a admin can approve of a funds transfer

In the above case I do not find any need to model this role in domain, as their are no rules distinguishing one admin from another in my domain.

Any person/userlogin with the permission of admin can perform this action, I would rather design this into my security infrastructure and ensure that the

approveTransfer() method invoked on the application layer is invoked only if the currently logged in user has the ADMIN permission.

So the "domain model" by which i mean classes like the Account class and unaware of this rule, this is codified in the application layer either via AOP or probably the AccountService class or the like.

What do the wise men have to say about this ? :)

Posted by: sudarshan89 <at> yahoo.com


Large domain, small team: how many contexts?

Hi all,

For the last year, I've been part of a small team of 2 developers working on a large project that is usually tackled by much larger teams. We are trying to drive the design of our domain model using DDD principles. We are succeeding to a certain extent, but we are struggling with the definition and separation of bounded contexts. I would like to request your advice on this problem.

To sum up the purpose of our application, we could say that it allows organizations to plan, track and report on collaborative projects. The main features are as follows:

  • user management
  • organization management (internal org chart, employees)
  • relationship management (customer / vendor accounts, contacts)
  • ratecard management (services, pricing models)
  • budgeting
  • project tracking (task assignment, progress and completion, etc.)
  • procurement (requests for proposal, business proposals, purchase orders)
  • accounting (invoices, receivables and payables, payments, collection, etc.)
  • reporting (budgeted vs invoiced, employee productivity, profit margins, etc.)

There is a strong requirement for traceability between entities throughout the process: one should be able to reconstitute the path from an original budgeted line item up to an invoiced line item, thereby allowing an organization to produce high-quality reports.

Reading the literature (both the Evans and Vernon books), I gather that bounded contexts serve multiple purposes: defining a linguistic barrier within which concepts are clear and unambiguous, allowing teams to work in parallel with minimal friction, and reducing coupling between different pa rts of the model. I also gather that an application may be divided in bounded contexts of varying granularity, ranging from a single coarse bounded context for the whole application down to several fine bounded contexts, one per feature. Given the application we're working on, and the current size of our team, it's unclear where in that granularity spectrum we should be standing.

There is a case to be made for having a single bounded context:

  • Our team is small, we communicate easily and we have a low integration cost.
  • We have elaborated a clear vocabulary within which concepts are clear(ish) and ambiguities are few and far between.
  • Integration between features is a selling point for this application, and so some entities are to be used by several features (e.g. a ratecard element can be used in a budget, a project timesheet and an invoice)
  • No duplication. An organization is an organization is an organization.

There is also a case to be made for having several bounded contexts:

  • Although our team is small today, we hope to grow in the future. Both communication and integration will become harder. Bounded context s would help us grow more easily.
  • The application will assuredly grow, and so will our vocabulary. Ambiguities and polysemes will surely appear. Bounded contexts would help us better contain and demarcate models.
  • Already, some concepts are used differently depending on the feature they live in.
    • For example: a ratecard element is used as an entity within the ratecard management feature (allowing for change tracking and an approval process), but it is used as a value in other consuming features (where it is considered to be stable, valid and approved).
    • Another example: an organization is responsible for hiring an employee within the organization management feature, while it is responsible for launching a project in the project tracking feature. Having separate implementations of the organization concept would allow for classes with clearer responsibilities (instead of having a God-like organization responsible for creating everything).
  • Already, changes to a central concept (customer / vendor account) has rippled throughout the model because of the high coupling to it.

As an experiment, we have attempted to separate the application in a few contexts. We saw some advantages: lower coupling between features and clearer responsibilities for classes. But we also saw some drawbacks: *lots* of duplicated code (n implementations of Organization, n implementations of Customer, etc.) and *lots* of translation code between contexts, which leads us to questions such as "why didn't I just use the original entity instead?" It also brought some questions regarding the visibility of concepts, such as "when defining the vendors to invite to a RFP, should I consult the relationship management context or the procurement context? and so will I need to add similar API endpoints to retrieve vendors in every consuming context?"

Needless to say, these questions are driving us mad and leading to discussio ns that, while interesting, ultimately leave us feeling like a) we don't understand anything, and b) we're losing our time on over-architecture.

So... if you're not exhausted from reading this, what advice could you give its very confused author? :)

Thank you very much in advance!

Posted by: gbilodeau <at> yahoo.com


composing multiple bounded contexts in a single user interface

We are developing a system which is composed of multiple bounded contexts, there are user interfaces where the information displayed needs to be rendered from multiple bounded contexts.

A classic example of such an interface is the Amazon.com ordering page. Where we see about about the product (product BC), inventory available (Inventory BC), prices and so on

My question, in such scenarios in which bounded context would the user interface live in ?, I get how we can pull data from multiple BC's to form the page, but are their in guidelines as to where the page itself will reside ?

Similar questions here and here, they deal with how to get information from the multiple BC's, but they do not address in which BC the user interface itself will live in ?

Any guidelines on that ? With an example would be great...

Posted by: sudarshan89 <at> yahoo.com


Framework for managing domain events

I am trying to learn how to implement domain events and use them to integrate various bounded contexts. I've read Vaughn Vernon's Implementing Domain-Driven Design, but as the book aim was to introduce the concepts, so most of the domain events generation and handling was done manually.

In the Java world is there a framework(s) that can be used to handle events generation, publishing, consumption, error handling,,,,etc?

I understand that I might be mixing several concepts here. For example maybe the events generation can be done by one framework and managed by another framework.

Can someone please recommend the current best tools to automate the management of domain events from end-to-end in Java?

PS: I'm not looking for anything related to Event Sourcing.

Posted by: songoko20000 <at> yahoo.com


Are web applications complex enough to domain-driven design?

After much reading and some attempts to implement DDD, I think I understand what people mean when they say the concept was developed for complex domains.

I usually develop web applications for small and medium businesses, usually the interactions are just CRUD application and tables in HTML, which goes beyond this are some validations before inserting the data into a database.

I was reading about CQRS on Martin Fowler's website and a phrase caught my attention: "CQRS is suited to complex domains, the kind that Also benefit from Domain-Driven Design.".

So my question would be how to analyze the complexity of the software?
When applying DDD worth?
Worth applying DDD in software for small and medium complexity?

Thank you!

Posted by: lc <at> leocavalcante.com


Introducing VBooky.com - Help for popularizing and any support!

Dear All,
  It's been sometime since I have got in touch with many. Here's a few updates on what I have been upto.

For the past 6 months or so, I have been working on starting up a company - Fyno Pvt. Ltd. and bringing up a product in the domain of Spa, Salon and Wellness. Now it's been in operation (beta) for the past 1 month or so.

Online Product - www.vbooky.com 
What it is - It is a online marketplace and platform for Salon, Spa & Wellness Industry, India
What You can do - You book your salon , spa services online like your next hair cut or pedicure or relax with a deeply soothing Swedish Massage .. & many more.

Brief Intro Video 

It is still in Beta even as we try to streamline the operations and few technical issues. Any feedback is most welcome :-) 

I need help and support in below areas. Any help is most welcome :-)

1) Popularize the website - Please register, login & book. Please invite at least 5 friends and make a booking. As of now bookings are only for Bangalore locations. 

2) Like Us on Facebook & invite your friends too

3) Spa and Salon tieups - We are working to get as many salons and spas online soon. If you can provide any more, if not not yet listed & you want them, please send the details .

4) Any good publicity - media, online, blogs & introductions & ideas - most welcome. 

​Sorry, if this mail has reached unintended inbox. My sincere apology. I have tried to remove irrelevant email id from my contact list.​

Thanks and Regards,
Ingudam Manoranjan

Posted by: Ingudam Manoranjan <ingudam <at> gmail.com>


Revenj - a DDD friendly framework

Hi all,

we've released a .NET backend framework we've been using for years.

It supports rich models (even has some support for unstructured ones) on top of Postgres (and Oracle) so it allows for seamless DDD while avoiding the JSON DB route.

It's BSD licensed and is available on: https://github.com/ngs-doo/revenj

It contains some distinguishing features (with https://dsl-platform.com/ integration):

 * advanced object-o riented LINQ driver

 * no ORM issues since it utilizes objects in the DB [so it might have OOM issues ;)]

 * integration with modeling language based on DDD for describing the domain

 * automatic SQL migration based on modeling language diff

 * removal of various boilerplate (repositories, DTOs, etc...)

 * works on Mono

If you have questions or comments, please let me know.



Posted by: rikard <at> ngs.hr


Assigning responsibility for cancelling an Order

During a conversation with our Domain Expert we can across this feature:

"A Customer service agent can cancel an Order by decreasing its quantity. To cancel an Order we decrease its quantity by the specified quantity, change its status to either partially cancelled or fully cancelled and log the CS agent who issued the cancellation."

We are currently split between several solutions (assuming we have the `agentId`, `orderId` and `cancelledQty` from the request): 

**Solution 1:**

    CSAgent agent= (CSAgent) EmployeeRepository.getById(agentId);

    Order order= OrderRepository.getById(orderId);



**Sol ution 2:**

    CSAgent agent= (CSAgent) EmployeeRepository.getById(agentId);

    Order order= OrderRepository.getById(orderId);


**Solution 1** really captures what the requirements is conveying and reads really well; however, **solution 2** seems more natural when coding the implementation of the cancel() method as I'll mostly update fields in the `Order` class itself which I hope to keep `private` with no public setters.  

The only thing I need from the `CSAgnet` class is a snapshot of its data to be stored with the `Order`.

So how should I determine the best course of action from a DDD perspective?

Posted by: songoko20000 <at> yahoo.com


Thoughts about the Repository pattern and its implementations

Please, take a look at Repository knows about the database schema, a let's discuss:


Posted by: lc <at> leocavalcante.com


agrregates vs. aggregates

getting ready for Friday Sept 19th, 2014?

Posted by: Raoul Duke <raould <at> gmail.com>


Yahoo Groups Links

<*> To visit your group on the web, go to:

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    (Yahoo! ID required)

<*> To change settings via email:
    domaindrivendesign-digest <at> yahoogroups.com 
    domaindrivendesign-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    domaindrivendesign-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo Groups is subject to:


Understanding Agrregates

If I have a Customer and a Product and they are related by a Account.

Account than is a Aggregate?

I will have:



Or my Account still an Entity?

Posted by: lc <at> leocavalcante.com