Tag Info

New answers tagged

3

The rule is not to depend on infrastructure, but instead you can create an interface in terms of the business to communicate with that infrastructure. These are your services. Sending mail is a business requirement, or service, but how you send mail is up to you. You may want to create your own business-specific mail interface, and one of the ...


2

Your question is exactly the question that is answered by reading Domain-Driven Design. The comment from Andy is spot-on. The entities don't depend on DAOs. They depend on abstractions that represent operations the entities need to function. The fact those abstractions represent data storage and are implemented using database is irrelevant to entities or ...


1

What do you mean by But then Agent shall depend on 3 DAO classes for just one responsibility? If you're talking about avoiding DAO call from domain classes, maybe you can design it like this: class Agent { List<Card> assignedCards; int numberOfRemainingCards() { return assignedCards.size(); } void sell(Card card) { // do ...


0

Your problem is exactly same kind of problem this exercise on software design describes. Instead of designing the code around specific device, you should design abstraction that describes process of reading a card. Then, this abstraction can be concretized to specific devices. If you design you software this way, the problems you are facing will be solved ...


2

It's perfectly fine - indeed, it's a good idea - to use dependency injection in your domain model. You should to develop your domain model independently of any particular technology or library. The particulars of such-and-such database or so-and-so library are not the concern of your domain model: if you need to swap databases your business rules will ...


0

Firstly I'd start off with the UI, thinking about the tasks/commands users need to perform and the data involved in each task/command. This is known as a Task-Based UI approach. These tasks will form a 1-1 mapping with methods provided by the Application Services (different to a Domain Service). Then I'd design my aggregates based on these tasks & ...


1

I don't think that id is a database artefact. How do you know that account you are working with is correct? You know it's a correct account because it probably has a unique identifier. In your case the unique identifier is called "Id", so naturally you think it's a database artefact. Because of this I think that it's perfectly fine to have Id property in ...


4

It depends. If your Account class shall be mapped to a relational database, then its not just a good idea, but proven practice, to use technical IDs for every table as PKs (and FKs, referencing those PKs). To my experience, separating the technical PK of all tables from the "domain keys" (like the "bank account number") works very well and helps you to avoid ...


4

Choose solution #1. There is nothing wrong with setters containing validation or coercion logic. In fact, that is the only reason why we'd use setters and getters instead of public member fields! Your create factory method is also a bit awkward, as there is no reason not to use the constructor instead: public class UserCredentials { private String ...


1

I'd go with Option 3, with the following notes: Try and reduce the amount of domain logic that your clients need to know to get the job done. Create services that expose that data in meaningful (to your clients) ways, so that you can request collections of domain objects which fulfil certain criteria, rather than doing that crunching on your client. ...


1

what could be the User object Behavior ? I cannt find any ! login, its an auth lib. thing so i should not include it in user. posting articles is a Post object thing; again user conduct it; but its more of a post object concern to create a post right ? User may be the main Aggregate object in a blog; yet the user is more like the Creator of ...


0

There are no limits to allowed methods in an object, but there are philosophies about behavior when it comes to good design. There are many heuristics (rules of thumb that don't offer guarantees of a good design, but which have shown merits in the past). As stated by Bart, software object behaviors can be classified as accessors (which don't change the ...


5

There is no hard and fast rule which methods an object must have. Something is an object if you can talk about it as an entity with a name that is familiar to domain experts in either your problem domain or the solution domain. In essence, if you have a related set of properties and behaviors that you can refer to by a single name, then that set of ...


1

Several reasonably successful implementations I have seen/built answer the question in how they mix the verb+noun metaphor using coarse-grained 'business friendly' methods that act on the entities. So instead of the (doomed) getName() method/service, expose getPerson(), passing in things like identifier-type/ID, returning the entire Person entity. Since ...


3

You were doing it right - load the file into a dummy table (preferably on a staging DB), then manipulate the data with stored procedures (which are easy to test - they're little more than a single function, and you can put test data in the tables and run your sprocs using that data in a transaction that can be rolled back so they can be very isolatable ...



Top 50 recent answers are included