Question about packaging

[yami12376]

Hey,

I am wondering is it better approach to use packaging by feature instead of packaging by layers using DDD.
In what direction your example packaging expand in the future?

Just by looking at the package structure:

└── library
    ├── catalogue
    ├── commons
    │   ├── aggregates
    │   ├── commands
    │   └── events
    │       └── publisher
    └── lending
        ├── book
        │   ├── application
        │   ├── infrastructure
        │   └── model
        ├── dailysheet
        │   ├── infrastructure
        │   └── model
        ├── librarybranch
        │   └── model
        ├── patron
        │   ├── application
        │   ├── infrastructure
        │   └── model
        └── patronprofile
            ├── infrastructure
            ├── model
            └── web

Does it start to use packaging by feature?

[shuraa]

Packaging by Components looks more straightforward to me. Component is term from C4 model. вт, 1 окт. 2019 г. в 10:55, yami12376 <[email protected]>:

Hey, I am wondering is it better approach to use packaging by feature instead of packaging by layers using DDD. In what direction your example packaging expand in the future? Just by looking at the package structure: └── library ├── catalogue ├── commons │ ├── aggregates │ ├── commands │ └── events │ └── publisher └── lending ├── book │ ├── application │ ├── infrastructure │ └── model ├── dailysheet │ ├── infrastructure │ └── model ├── librarybranch │ └── model ├── patron │ ├── application │ ├── infrastructure │ └── model └── patronprofile ├── infrastructure ├── model └── web Does it start to use packaging by feature? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#41?email_source=notifications&email_token=AAGK4DM252VG5GZXROYP4KLQMMF65A5CNFSM4I4GQ6VKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HOY5XHA>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGK4DIPOFT6IQ3DDGONUB3QMMF65ANCNFSM4I4GQ6VA> .

-- Best regards, Alexander Morozov

[bslota]

Hi! Thanks @yami12376 for your question! Could you please elaborate on what do you mean by "(...) direction your example packaging expand in the future?". Just like @shuraa wrote, we follow packaging by component, to get screaming architecture, minimizing architecture code gap. Currently, each component package encapsulates the "features" in the form of queries or applications. The key in understanding the reasoning behind it is that there are aggregates that create the heart of their own package - in other ones, they are just projections (read models), or they are not even known (event-based communication). Thanks to this, we get clear separation of concerns. Does this description help you?

[yami12376]

each component package encapsulates the "features"

I meant if you can make package by feature inside of packaging by component?
I do not see it yet in code - is it possible?

If not, what are benefits of using packaging by features instead of packaging by components?