Add a comment


Re: Layers, hexagons, features and components

Hello Simon, I like your articles about web software architecture.

I'm developing a new project from scratch trying to implement a "package by component" style. But one of the problems I have is how and where to put the generic data access services and daos, that I had when I used layers.

They implement the tipical crud operations and some search methods, and concrete services extends them in order to dont repeat code.

How do you deal with it? I've thought on having a generic data access component from which the concrete components extends. Do you think it's ok?

I see two problems here...

(1) Doing this it's like having an hexagonal architecture (data access component for accessing the external database)

(2) Generic data access component breaks encapsulation, as it has public implementing classes, for letting concrete components extends them.

The later can be solve using composition over inheritance, but I really don't like it very much, because you have to write lots of forwarding methods.

Another doubt I have is wether you have shared domain entities and database, or if you split the database, and every component has its entities and database tables. My approach is to have one database (and one entities package), shared by all the components. But if you split the database how do you deal with relationships between entities of different components?

Thank you very much.

Re: Layers, hexagons, features and components

HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
E-mail address
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).