2
votes

I am involved in a project for building a webapp for something that can be described as a rule engine, we are using DDD approach to capture and model the domain and the functionalities.

But what about application related data, since it is a web application there will be a significant portion around security/user-mgmt, log mgmt. etc., miscellaneous items that are not part of the domain but there will be data that requires to be managed for them. From the initial reading of DDD paradigm, we get a fair idea about domain model, and persistence through repositories. Application specific concerns like security, txn mgmt etc are to be contained in Application Service layer is what i understand.

In this where/how persistence of application specific data ? Should that also be modelled as different aggregate and be part of the system in similar way or should those be structured in a different way(Manager classes talking to DAO - like Transaction script) ?

1

1 Answers

4
votes

I think security, logging, etc is not what domain experts are talking about. These things are not part of Domain, and should not be designed as domain entities/aggregates. If it is not designed as entity, it should not be persisted as entity.

I think these things should not pollute domain model. Security or logging is a part of infrastructure layer. And persistence of such things should be managed by infrastructure layer. Consider about logging: you can log to files or to database. And you should be able to switch easily between types of log persistence. Same with security - database or ActiveDirectory? These things change independently of domain model persistence, so you should not mix them.