Layered architecture allows us to logically stack up the application code serving user demands based on the data sources. As more and more features are added to the application we add relevant code to each of these layers. This increase in code size of each layer can be considered a necessary complexity. Naturally, the classes in upper layer depends on the layer below it. But there is another kind of dependency or coupling which starts to creep in. The classes within a layer start interacting with each other. In our architecture this is most prominent in domain layer. The domain layer models the problem and we design it to communicate the problem space, while other layers are task oriented to be read as the narrative of a process. This doesn't imply that other layers are completely void of such couplings. A good test of coupling is answer to the question "what all can get affected when I change one class". It is less likely that changing the presentation code in one area of application may have much affect in other areas, but it is harder to say the same about a change in an entity class. This is because so far in this book, and in general in practice, we don't define any boundaries in the domain model. Each part of domain model is theoretically accessible from other parts. Essentially everything is related to each other in database and in domain model via OR mapping.
This doesn't allow us to change the code without fear. Entities and aggregates are the only abstraction units we have. This is not good enough when you have hundreds of entities and few dozen aggregates. We need next level of abstraction to break the monolithic nature of our domain model. The chapters in this section of book provides few techniques to achieve this.
Module interaction (Tell don't ask working at various levels, persisting ids when data is created across different modules in the same call and there is foreign key relationship)
Presentation modules (interact using session state, testing by setting session state, solving performance issues when two modules on a same page requires similar data)
Infrastructure (hibernate configuration, session factory, session, connection) sharing
Cross module joins
Notes:
Separate services for inter-application and inter-module communication.
Ivy+Ant over maven: one downside the module dependency has to be defined twice in build and IDE.
Classes belonging to lower module should not have semantic knowledge of the dependent modules. (Since customer is agnostic of its usage, making it know of loan is a bad idea).
If reference data is used as module and reference data is to be deleted. What is the best way to check for the dependency on it. Because of non-functional nature of reference data one might use the database route to solve this. But in case of other dependency of data, deleting of one might have be handled differently. Delete product and how it is handled by loan.
Explain in benefits of modularity, performance of load because of lesser hibernate mapping, there are fewer tests and when working within the boundary the development feedback is better.
No claims that creation of modules actually allows for creation of independent teams
How do I getNextMeeting date for a loan as it is dependent on the customer's meeting, but in a modular world I don't have the customer object in loan.
share succor classes and put mother there
Reference: