New answers tagged

-3

Well, it depends on how you want to look at it. Another way is: "Is Single Responsibility Principle violating Domain Entity?" Both are guidelines. There is no "principle" anywhere in software design. There are, however, good designs and bad designs. Both these concepts can be used in different ways, to achieve a good design.


0

The employee may or may not be a or the user. A user is part of the application domain, maybe not at all of the domain. I would associate a user with an employee. You may want to keep track of a 'former' employee also after they are no longer a user. Inheriting from user would be unfortunate then, there is no is-a relationship there anymore. Further sub-...


0

The usual procedure for syncing rows in a database would be to initiate a transaction session. Before updating your row you read a second instance of the same row from the database (during the transaction session to avoid changes in the meantime) and compare any column's data for changes. As comparing any column can be a performance intensive task especially ...


0

I believe you missed a point here, your Aggregate root should be your Test Entity. And if it's really the case I believe a TestFactory would be best suited to answer your problem. You would delegate the Question and Answer building to the Factory and therefore you could basically use any solution you thought of without corrupting your model because you ...


0

I'm wondering the following: suppose we are building a system where there needs to be some filtering functionality to search for some entity. For example, one might want to apply the filtering to a table listing the entities to find something, or use it to generate a report on a filtered set, whatever. You should observe that this point that your use cases ...


0

The data mapper has to know about the unit of work. You would typically pass the UoW to the mapper using DI. I understood why they are both important and when to use them but, I couldn't find anywhere how the Data Mapper can "know" that a save method, for example, was called in the middle of a transaction or not. A single UoW instance represents one ...


0

The boundary for a Unit of Work is time. It answers the question: What all are we changing in this one transaction? The boundary for a Data Mapper is space. It answers the question: What all is part of this one data structure? The unit of work is used to prevent hitting the database to often by sending every little chunk of info one at a time. The data ...


0

Here is the best analogy that i've been able to "teach" to my co-workers when wanting to work on DDD with Value Objects. Everytime you think of a Value Object, think of DateTime object in .Net. For example, when you have a DateTime in your object, and you persist that object, you are only saving a string representation of the date and time in question. It ...


3

Onion architecture is one of the possible choices when you use DDD. If you decide to use it, the implementation should be in the infrastructure layer. You can have several implementation of the same interface and inject the required one in your application. IMO the interfaces themselves should be in the Domain layer.


1

Depends on what your interface returns. Assuming they return domain entities they should go in your domain layer. The actual interface implementations can go in your persistence layer. When you have your repository interfaces in the domain layer the layers above does not depend on your persistence layer. From a conceptual standpoint the idea that you get "...


1

No, this breaks the encapsulation of the aggregate, because Event is referencing Child, which is under other Aggregate root. All 3 should be roots.


2

If Cycle belongs to a particular ScholarshipProgram only, then it should belong to the ScholarshipProgram aggregate. If a Cycle can be part of two or more ScholarshipProgram, Cycle should be its own aggregate root. In any case the aggregate root is your entry point. In the first case that means that ScholarshipProgram would have the methods to manage Cycles ...


2

While there is some logic in having the methods that do some operations with bill history in the CustomerAccount (or Bill) class, one might argue that having them there breaks the SRP. You could say that CustomerAccount class should be responsible only for maintaining the account data (adding, deleting or modifying that data). Reporting could be seen as a ...


1

Apart from what Alexander Langer said, there are not only good reasons for, but actual security policies for going even further and don't even hold any kind of credentials or temporary tokens in your domain logic. Practically speaking (and I apologise for not knowing DDD or the exact case well): the domain logic (BC, WebService, whatever) rarely has to ...



Top 50 recent answers are included