Tag Info

New answers tagged

1

Customization is as simple or complex as introducing any other requirement. Each time you add a custom business rule or a business rule modification to your application, analyse how to make this rule visible or invisible, active or inactive, available or not available by some kind of run-time switch. Think of the customization step just as an extra, ...


0

The question you should be asking yourself is if the effort saved on maintenance (by not having to change code for future user requests) or the additional versatility (such as being able to easily convert and market the app to different users) are worth the additional effort of creating a more generalized system. Don't write a universal condiment dispensing ...


0

JDT's answer is pretty good, but another option you might want to consider is a domain-specific language (DSL). In this approach you define a simple language to capture your workflows, provide primitives for specialized checks and steps, etc., and then write an engine to interpret and execute them. By keeping everything in a database, or hard-coded, you ...


3

I can think of two possible solutions here, but they both require a fair amount of development (but I really can't see a solution where this is not the case). I would also recommend not developing any specific kind of check step until it is actually needed. It's very easy to have requirements for 42 different kinds of automated steps that end up having only ...


1

If you have an entity as in a DDD-entity (not what is generally called an entity in frameworks such as entity framework) then the entity should protect its invariants. Thus using the entity as a DTO is most likely wrong. A DTO is unvalidated input data from the user and should be treated as such. An entity is validated data in one of the object types valid ...


0

If your presentation layer is always co-located with your Data Access Layer (DAL), which is often the case for server driven web apps (or standalone GUIs), you should typically not need a DTO layer: just use the entities directly. If your presentaion layer can be remote, then DTO is a good idea. And, yes, a DTO can be used inbound as well as outbound, i.e. ...


5

Usually, services call other services when they need to access their data. Each piece of data should belong to a particular service which will be the only entry point to accessing this data and modifying it. Some services will be simple and usually correspond closely to your domain model (e.g. a service for handling users) while others will be high-level and ...


1

The application primarily deals with users, profiles owned by users, photos, and tags that represent one to many profiles in a photo. There would conceivably be methods to return photos uploaded by a user, return photos that contain a certain tagged profile, etc. Well, profile service should not work with user object. It may know only the ID of ...


0

I suggest that you should separate the Customer and SocialInsuranceNumber entities into their own classes, as clearly both contain data and have behaviour: Create a SocialInsuranceNumber class, and move the isValid() method into this class as a static method isValid(int CandidateSIN). It could be a member function, but that means it is possible to create ...


0

Well, I don't see any problem here, actually. To consider something to be a validation rule of the object, you must be able to take an object and tell me exactly how do you validate this object to satisfy the rule. In your case there is no condition clearly defined when to apply this rule, so I would say you have no validation rule at all ;) ...in some ...


0

We can solve any problem by introducing an extra level of indirection. I doubt that adding another level of abstraction would solve your problem. I think the question you should be asking is 'do I need two repositories for this or just one' and the answer to this depends on a lot more than can be found here... No harm in starting off with the one Dog ...


1

Your first approach looks much cleaner than the second, but I do not think you have to sacrifice performance necessarily by choosing this design. Assumed it turns out the approach is really not efficient enough, then you could use your PDFDocument as an abstraction over your preferred pdf representation "behind the scenes". What you call a PDFDocument, does ...


4

I sounds like you're trying to create an adapter around a third party library to avoid it becoming coupled in your business logic. Out of the two approaches you mention, the first one seems the best idea, as it's the most flexible and you can separate your business logic from the adapter (i.e. the adapter will basically be a pass through to the third party ...


0

My concern with your solution would be the overhead of maintaining user permissions, depending on how many users you have and the turnover of users. Evey time you get a new user you will need to add a whole stack of permissions "canViewProduct", "canViewOrders", "canPlaceOrder" etc. etc. etc. In larger shops this is usually handle by splitting the problem ...


0

there are several good ways. You could implement open-closed by always using a factory to get the Guardian and returning a subtype of guardian that inherits the previous version. New functionality could cast to the most recent subtype. You could also implement open-closed by just ... Adding methods! And knowing not to touch others. While this is easier ...


-1

Your solution is okay. Security and accessibility are pervasive in your system so having to add methods as permissions are added is workable. Using character strings to identify permissions is okay in a PHP program since you won't ever find out that your code is wrong until run-time anyway. Character strings can be composed as well: if ( ...


2

The guardian shold have a public boolean checkPermission(String permissionTag, int userID); method. That way the guardian doesn't have to change when new permissions come to exist. Usage if (guardian.checkPermission("PLACE_ORDER",loggedUser)) { // place order }


0

The View model is a different bounded context from your domain model. So you need a context map to map between them. Your domain services should produce domain entities and value objects. The mapping to view models is a different responsability. If the domain service would produce view models, it cannot be reused.


0

I would look into the shared kernel. This is where two teams share some subset of the domain model. I wouldn't duplicate data but create a library where both parts of the domain are combined. It's not for everything in both domains but the parts that are needed to make meaningful use of both domain's in one place.



Top 50 recent answers are included