Home/ Questions/Q 8992601
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T22:59:37+00:00

I know the title probably isn’t too clear because I probably don’t have the

  • 0

I know the title probably isn’t too clear because I probably don’t have the right terminology, but an example should make it clear. Suppose I have an app with posts and comments, what would be the best practice as far as grouping those into namespaces/packages of the various ways. If there’s no better way, what are the advantages and disadvantages of both. Here are a couple different ways I envisioned, note this is in no way exhaustive, it’s just to get the point across:

1)

MyAp
|--Entities
|  |--AbstractEntity.class
|  |--Comment.class
|  |--Post.class
|--DataMappers
|  |--AbstractDataMapper.class
|  |--CommentDataMapper.class
|  |--PostDataMapper.class
|--DataMappers
|  |--AbstractService.class
|  |--CommentService.class
|  |--PostService.class

2)

MyAp
|--Abstract
|  |--AbstractDataMapper.class
|  |--AbstractEntity.class
|  |--AbstractService.class
|--Impl
|  |--Comment
|  |  |--Comment.class
|  |  |--CommentDataMapper.class
|  |  |--CommentService.class
|  |--Post
|  |  |--Post.class
|  |  |--PostDataMapper.class
|  |  |--PostService.class

With a big project, you could break either one of the methods above into broader groups. For example, for #1 you could have Db, Util, System, etc. beneath your Entities, DataMappers, and Services namespaces and would place class implementations in there while keep the AbstractEntity class under the Entities namespace. For #2, you could do the same putting those additional namespaces under Abstract and Impl.

I’m leaning towards #1 being better, seems like I would have to add additional Db, Util, System, etc. namespaces to 2 different places. But #2 has the appeal of keeping all classes related to one model class together. Can’t make up my mind!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’d say there’s something wrong in both approaches.

    Most of developers tend to break classes by their main specialization. Mapper should go to mappers, model should go to models, helpers should go to helpers, interfaces to interfaces, we think first. That can be easy decision an the beginning of the project, but it causes some pain as time passes. It looks rather stupid some times. Especially when you need to extract a certain functionality into a separate component.

    From my experience I can say that you should group classes by their high-level function, or ‘sub-system’, or, as now DDD specifies ‘bounded context’. In the same time there shouldn’t be very may grouping levels.

    So – I can see all of your entities belong to Posting context. It can look strange enough, but I’d suggest that you put all of your classes to Posting fodler and do not create extra subfolders unless you have a very specific functionality area within the context. 

    MyAp
|--Core
   |--AbstractEntity.class 
   |--AbstractDataMapper.class
   |--AbstractService.class
|--Posting
   |--Comment.class
   |--Post.class
   |--CommentDataMapper.class
   |--PostDataMapper.class
   |--CommentService.class
   |--PostService.class

    In general your second approach looks similar. In that case you can easy add more and more context-specific folders. Something like – ‘Voting’, ‘Notifications’, ‘Authentication’, etc. Also I’d suggest to choose the simplest way, and wait until you have some ‘critical mass’ of classes so you’d have enough information about how to group classes correctly.

    With the first approach you domain’s contexts would be spread over all folders.

    • 0