Should business services cross bounded contexts?

Posted by Paul T Davies on Programmers See other posts from Programmers or by Paul T Davies
Published on 2012-10-18T13:45:42Z Indexed on 2012/10/18 17:24 UTC
Read the original article Hit count: 194

Firstly, I am following the convention that a bounded context is synonymous to a department, or possibly one department has 1 to many bounded contexts.

We have a client consultancy department that has a Documentation Service. Documents are stored in the Document Store Service (which is where all documents in the company are stored - it is a utility service), and the Documentation Service stores information about that document (a business service). As it was designed for the client consultancy, it is information relevant to them.

Now health and safety need somewhere to store information about a document. This is different information to client consultancy, but I have been instructed to extend the existing service to account for this extra information. I feel this service is now crossing a bounded context. My worry is that all departments will eventually store there information in here and the service will become bloated, trying to be all things to all departments. Each document record will only store a subset of the information because it will only belong to one department.

It will get worse when different departments want to store the same information but refer to it in a diferent ways, or when two departments want to store different information that they refer to in the same way. In my understanding, this is exactly the reason for bounded contexts.

I feel each department should have it's own business service for information about a document, but use the same utility service to actually store the document.

What would be the correct approach?

© Programmers or respective owner

Related posts about architecture

Related posts about enterprise-architecture