I am new in hybris and I want to know how Basesite,Basestore,site and store are different from each other. And can one base site have multiple basestore and vice versa.
From Overview of the CMS2 Data Model:
A CMSSite is the entry point to a website. A CMSSite is assigned to
one or more stores, known as base stores, which define the product
catalogs and the versions that should be available in the website.
You can treat BaseStore as a physical shop, and a BaseSite/CMSSite as a website. A site can cater different stores. The relationship between BaseStore and BaseSite is many-to-many.
Related
I was promoted recently as a software architect in a Software development company that produces an Enterprise Content Management product for a customer segment that includes the likes of Insurance companies, Healthcare companies, Research companies and Government agencies.
I had designed moderately complex applications at this organization and my previous jobs.
As a new architect I want to explore Domain Driven Design concepts and various architecture types for migration of our product to a cloud service provider and metamorphize our product from a media based deployment to Software as Service (SAAS) offering.
In my opinion to do this correctly, I will need to create a domain model from the domain for which the software is written.
However the problem I am having is determining what the domain for a product software company is when their products caters to varying needs of disparate customer verticals. I suspect the domain is some kind of meta-domain and not a regular business domain like shipping, insurance or healthcare.
I have following question for this scenario
Question: In terms of Domain Driven Development, what would be the domain of such a company and how can I articulate it so, I can create a domain model?
Identifying the Core Domain can be tricky because the core purpose of your software application can be obfuscated because of all the supporting features that need to be present to make the application useful.
These clues may help you identify and categorize functionality between your Core Domain and Supporting Domains:
Is your software no longer identifiable from a product outside your domain category if you remove a piece of the functionality? You are dealing with a Core Domain.
What is your company's Vision/Mission/Differentiator Statement? They usually reveal the Core Domain.
What category are you and your competitors grouped into in industry reports like Gartner provided? That is your Core Domain.
If your product addresses different customer domains, what common features are used by almost all of them? That is your Core Domain.
Is functionality an industry standard? Does everybody else have it too? Instead of building it, can you buy software off-the-shelf and integrate it into your application, if one were available? If yes, you are dealing with a Supporting Domain.
If you were to remove some functionality because customers do not use it or don't value it enough, would your product still be marketable? That is a Supporting Domain.
Answering these questions will point you in the right direction, but the boundaries of your core domain can be unique to your product's value proposition. Don't hesitate to expand and contract the core domain as the product grows and matures.
Most importantly, talk to your Domain Experts and Salespeople. They usually have a very good idea of what the product pitch is, what is the core value, and what are addons.
What I'm trying to achieve is to develop an application implementing the DDD approach.
The story might sound silly but it's an actual, real life problem. Believe me.
The business looks as follows:
Let's say a company specializes in manufacturing sweets which are distributed to its own shops for sale.
The craftsman makes different types of candy depending on what is - and what is not - currently at the display at one of the company's shop.
When a basket of one flavour 'disappears' the seller replaces this type of sweet with a different kind from the shops storage cabinet.
Duplicates of flavours at the display shouldn't exist and the display should be populated with as much as the capacity allows or how much the manafacturer can handle to produce.
The sweets are distributed from the manufacturer's lab's storage to the shop's one depending on the demand.
Let's assume each worker has public view access to the display and the storage cabinet. Each worker (user) decides on it's own what to provide. The shops display view will be publicly accessible through the application to a potential client as an information what is currently on sale.
So far I have split the business logic into three separate (sub?)domains which are:
Production
Distribution
Sale
And of course each entity like Sweets, Storage, Craftsman, it's Repository etc. are placed respectively in their domain.
The concerns I approach are:
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Is my reasoning proper? Correct me if I'm wrong or violating any DDD rules.
Thanks in advance.
The story might sound silly but it's an actual, real life problem.
This is great, actually. In his recent retrospective, one of the things that Greg Young called out is that "shopping cart" models are a really lousy as a teaching tool. He points out briefly that the interesting questions are in the supply chain.
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
No, but a message (DTO) describing an entity's state might be passed from one domain to another.
You want to keep the flexibility to define the entities differently in each domain; that's part of the point of identifying bounded contexts.
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Probably not: your domain model isn't the book of record for the storage cabinet. Listen very carefully to Greg's comments on one way commands.
I am a student developer with Oregon State University's Business Solutions Group and I am currently working on a Salesforce integration project for one of the University's colleges. As you can imagine, the data we are working with is coming from several different places and in a variety of different formats. I was wondering if anyone with more experience in setting up Salesforce object schemas could talk about the pros and cons of relational database style normalization in Salesforce. What do we gain by not normalizing and using Record Types to categorize data? (For example: a Person-Account that encompasses Students and Faculty and uses Salesforce Record Types to differentiate between the two) What do we lose?
This message was inspired by this webpage:
Salesforce Guru: Record Types
Notice that the first thing it advises is to not normalize (overmuch) because it prevents us from taking advantage of some built-in Salesforce functionality. Overall, the page seemed helpful, albeit incomplete.
The answer to this question seems critical to the success of our project and will help us to decide how to reorganize the data we are initially migrating to Salesforce and ultimately build our Salesforce object schema, so any thoughts, additional resources or advice are very much appreciated. Thanks!
The inspirational web page is correct. With the "standard objects" like Account, Contact, Case, Lead, etc. and even with custom objects the system works best to use fewer tables (objects) and segregate the data based on some value (such as record type).
By using record types you leverage the point-and-click UI. For example, for the Account object you have a default page layout. But for each record type you can have a unique page layout. Furthermore the security model uses record types to limit or grant access as appropriate to different user profiles.
As the author says SOQL is NOT SQL.
Pardon the length here...hopefully I didn't go overboard...
I'm in the process of working on my first production MVC application and I'm trying to stick to DDD principles in the process. I've run into some questions related to how to deal with the security requirements of the application and thought I'd see if the SO community could offer some best-practice suggestions.
Domain Information
To use a simplified explanation, this application will have AffiliateCompanies, Users, and Customers.
AffiliateCompanies are hierarchal, so one affiliate can sign up and be tied to the activities of another affiliate. The root is the main company providing the products/services.
Users all belong to an Affiliate entity.
Customers are organizations to which the products/services are sold. Affiliates are assigned to customers such that it is possible for two hierarchically-unrelated affiliates to split a Customer.
Security Information
Rights to perform certain actions in the application will be determined based on an ACL-type of arrangement. Each User object has a property that is a collection of SystemAccessRules that determine what actions they can perform and what the scope of their permissions are (their own objects, their affiliate's objects, or their entire hierarchy's objects). Users can also belong to roles, which themselves have that same collection of SystemAccessRules.
As a result, if a user logs in and wants to see a list of "their" customers, the list could be comprised of customers they are individually assigned to, customers anyone in their affiliate organization is assigned to, or customers anyone in their organization or any of their child affiliate organizations are assigned to.
Database Considerations
DDD aside, at some point the storage strategy has to come into play. In this simple scenario, the tables align with the objects above (including a roles table), with a few support tables to support the relationships between the objects:
AffiliateCustomers - this table allows for a many-to-many relationship between affiliates and customers by storing the PK of each entity as a pair of FKs that are themselves a composite PK for this table.
ACL - this table stores the security information, specifically the subject of the entry (either a user or a role), the action in question (e.g. "CreateCustomer"), the permission (allow or deny), and a scope (their own stuff, their organization's, or their network's).
The Question...Finally
I'm using a combination of repositories and services. I'm trying to keep business logic in the services and out of the repositories or database, but due to the security design here, a simple request for the list of "their" customers could be immensely burdensome, especially as the data set grows. I was trying to use Linq where possible, but this architecture seems not to be very suited. As I see it, here are my choices:
Accept the requesting user as an argument for service methods (or determine it by context), and have the service method populate a list through multiple queries to Linq repository. This would require pulling the list of customers, then iterating through each customer to issue another query to pull the ACL data, then using that data to filter the first list based on permissions. The hierarchy issue would require some fancy Linq footwork (like this), if it's possible at all.
Even if the hierarchy issue could be made to work, it seems like this solution won't perform very well...
Accept the requesting user as an argument, but pass it and the required permission (e.g. "View Customers") to the repository in order to retrieve appropriate data from the database through a stored procedure that would use several EXISTS clauses in a CTE query that could account for the hierarchical nature of the data and the need to check for role and user security.
This pushes a fair amount of logic to the database, which seems very anti-DDD and generally bad.
I'm leaning more toward the second option, but that may be because in my past projects that's how I've done it. I'm not even sure if my design overall is on the right track (in the past the permission declarations were done using bit flags, so it was even easier to do the DB query using bitwise operator).
Has anyone been in similar situations, and if so can you comment on the performance and maintainability of the solution you pursued? I want to stick to high-minded programming principles, but not at the expense of simplicity and common sense.
Have you considered using the specification pattern to pass your business rules down to your data access layer?
The service constructs a specification tree which it passes to the repository. The repository converts the specification into an Expression<Func<Customer, bool>> which it passes to IQueryable<Customer>.Where(...). When the repository materialises the collection, e.g. by calling ToList(), the business rules are translated into SQL and executed on the database server.
Last time I checked, LINQ to SQL didn't support CTEs, so you may need to use a view to flatten the hierarchy.
My workplace will be starting to use Sharepoint internally during the coming months. I'm pretty excited about the possibilities of having more structured data on our intranet. A key part of this is allowing related data to be spread across the site hierarchy.
I'm currently experimenting with a list of Committee Members, with the idea that somewhere on the site you could see a list of everyone on every committee. Then in other parts of the site, you only want to see members of a single committee. From the various articles and blog posts I've been reading, it seems like there are three accepting ways to approach this:
Roll Up - Subsites have their own lists (optionally from a list template). Content types are used so the instances can be collected into a Data View Web Part on the parent site.
Pull Down - A master list is defined in the parent and each subsite contains a view of that list, filtered
Purchase or create a custom rollup webpart.
What are your experiences in different situations? What are the tradeoffs of these techniques and are there other (good) ways I've missed?
BTW, the committee members example is what I'm currently experimenting with to try out different possibilities. I'm more interested in the general tradeoffs, not necessarily specific to this example.
Having done this a number of times on different sites, for your situation, I recommend:
1.Roll Up - Subsites have their own lists (optionally from a list
template). Content types are used so
the instances can be collected into a
Data View Web Part on the parent site.
This gives more flexibility, not only can other sites in your site collection get this information, you can use the search query webpart to roll up the information in other site collections (the CQWP and DVWP do not work across site collections).
The only time I have used a Pull Down model is when there logically is only one list that I site collection will go to. Such lists for us have always been functional in nature, e.g. A list of content query definitions for a some custom functionality or a list of customers that ALL sites rely on and is used to populate an installed custom field control.
I would say that both will work equally well but the advantages of one over the other really come down to whats more convinent for how you'll have your intranet site collection structured.
You might also want to consider using the Content Query Web Part (CQWP) in combination with a complimentar site collection structure so that you can surface the committee member data.
With a little customization, the CQWP can do some amazing things - and it has been fully optimized under the hood by the product group team for managing all kinds of queries. It's easy to configure and use, and there are plenty of examples on how to use them on the web.