I tend to agree with Eric Evans when he talks about Modules in his book. As before, reading his examples and considerations looks like someone who had seen most of what I have experienced as a programmer.
The technological layer architecture has been used in many of the projects I worked on and is one I always try to push onto the design of my applications, even recent ones. But after the initial benefit we get from the separation of concerns like database access, presentation, services as stateless classes, we end up with a set of layers that really don't like to be extended. Not that they are closed to extension, but the whole concept of the entity is scattered through at least 3 layers and if we use any work flow framework on top of it, we will end up having 5 layers to deal with.
I am eager to finish up this book and start trying out some of the concepts in small scoped projects just to see where it will lead the code in the end.
Anyway, modules should be used as a way to simplify the understand of any big domain-model by restricting a set of concepts based on a commonality between them. By using modules effectively we create this subset of functionality that should be easier to grasp than the whole myriad of disconnected information that is usually mangled together in a uncoordinated way in most of the projects I worked in the past.