I like domain driven design, and onion design. However I would really like my features to be encapsulated. If i check out some legacy code and I need to investigate some specific feature the best thing that I think could happen to me is that I see (lets say in java) is that there would be a package with
featurename and all the feature functionality would reside in that package. In a way that if i delete the package the feature would be gone.
While I understand its impossible because some of the feature might reside in other service I'm trying to at least think if its correct to do that in my own service.
My problem with this is that usually in
DDD and in
onion design you have the domain which contains a bunch of domain objects. now some of these objects are of "my feature" and some of them are of other features. lets say (user authentication is one feature and user twitter account details is another feature).
Is there any design methodology that does something with it? is what I'm suggesting makes sense?
Example: you have a project that manages users waiting in line. You are asked to add a limit, max on the queue size. you need to read that max queue size from configuration. Then in your logic you need to apply that max queue size. You also need to expose this configuration of max queue size in jmx, also you have an api to that service so you need to expose that max queue size as an api in that service.
Current app packages:
--> conf (deals with reading configuration) // do change here.
--> domain // do change here for that small subfeature.
--> logic // do change also here for that small subfeature
--> service (where api are) // do also a change here.
so in the above simplistic example for a simple
subfeature addition i need to make changes to at least 4 packages. Which means my subfeature is spread among these packages and classes.
boundcontext but notice my feature here is very very small! just adding a max limitation on size. So it does not seem appropriate to open a
boundedcontext on each such small subfeature.
So the way I deal with it today I go conf i find there a class named
Configuration which contains various configurations. I add to that
Configuration class a member named
I go then to domain to model that new property I have there lets say
Account I add to the
I go then to service an expose a new method named
as you see I went to multiple packages and multiple
classes already dealing with other functionality and extended them.
This is a very small feature, for one hand I cant imaging that for every small feauter I would open a whole new bounded context with its own
service, domain, conf packages (and lets assume there are more) so that each feature is in its own package.
On the other way on each feature I need to extend
configuration, domain, service, ... which means no single feature is encapsulated well enough so that I can just delete it or see a package which its fully resides in so that I can better understand the app.