I work for a smaller record label company that has distribution and office locations in the UK and US. They want to join the sites into one and use geoip to determine what content to show.
The UK has rights to show content that the US doesn't, orders in the US go to different distributors than the UK. Basically in almost every sense the functionality of the content is desired to work different. Licensing for example the UK uses different licensing with a third party and the US handles it themselves.
The stack plan was nodejs api as a central hub and SPA angular/javascript front end with an admin app under a sub domain.
Q1. I imagine for SEO it would be beneficial to have a .co.uk and .com domain instead of serving all from .com and changing content based on geoip?
Q2. I was originally planning to serve from a single API resource and return data attributed to different country/shops. But functionality wise there are different sections that use different functionality, such as licensing will function different in UK than it will US. Should the sites and data be independent, or should I try to make it work as a multitenant app and work through the different functionality based on the domain name? If I make a multitenant site it doesn't seem in areas of functionality that data will have the same structure.
Are you building that site yourself? It's not sounding like a one man job to be honest. The correct solution sounds like you need to break the two sites apart, however if you're a 1 man team then that's a lot more work.
To do both sites with one infrastructure you'll need to abstract it in the correct way and probably put on it a few layers that will decorate and template it. I wouldn't advise that simply because node.js apps were meant to do a small functionality very well, and not become huge apps serving multiple domains.
Related
I am working on a project that designed base on Domain Driven Design.
In this project, we have 5 layers:
Infrastructure
Domain
Application Service
Distributed Service
Presentation
I am confused about how to put my business logic among Infrastructure, Domain and Service layers. Sometimes I put the business logic condition in iqueryable Linq in a repository; sometimes I load all the objects to memory and put them into services; and sometimes I put them in the method of an object. I don't know which way is the right way. Which layer should be responsible for this business logic?
I need some concrete reasons to convince a team of developers that business logic in code is better, because it's more maintainable. I used to have a lot of business logic in the DB, because I believed it was the single point of access.
Stored procedure are usefull to speedup certain DB operations.
Stored procedure are evil because:
it's hard to versioning (not the hardest thing, but harder than versioning your project)
it's harder to deploy (e.g. in my job we have thousand of DBs with thousand of stored procedure's on a couple of servers; when we change logic of a SP we have to update every DB: a pain in the neck.)
it's difficult to debug,
it's difficult to unit test
Said that... implementation of repositories are infrastracture, and infrastracture doesn't know about domain and business logic.
After all I can't really see DDD in this question, maybe you should deepen concepts like entity, value object and aggregate root, together with repository and domain model.
The only thing that we can confirm right now is: Business logic intended as domain logic belongs to the domain model/domain layer. The domain logic is rules that act always in the same way apart from the use case (e.g.: if the order is more expensive than 100$ the shipment is free).
If you have a rule that depends on a use case (e.g.: if a user browse my e-commerce with the appmobile than ...) this is application logic.
DDD also follows the "seperation of concerns" rule so business around domain stays in domain layer and if something outside of domain is dependent then we put them in higher layers like model views in presentation layer.
I know this is old, but I've had some experience working on older projects where the database held all the logic and various systems used that logic. Updating any of those systems became a nightmare of making a change to any of it would break something somewhere else.
DDD was built to get around these exact scenarios.
Think of it as you having one focused application that controls it's domain, defining the domain is often hard, but lets say you could define a traditional system with 3 domains.
Commerce Domain controls how to take orders.
Logistics Domain controls how to ship orders.
Billing Domain for how orders are paid for.
Each one of these domains would ideally be represented layered applications, but the whole end to end story of an "order" involves all 3 applications. Each domain controls it's business and is responsible for doing it's job the best way it can.
Billing Domain could be as simple as a web api that appends order data to a csv file that someone in accounting opens once a month and hand types an invoice out. Or it could grow into a massive complex beast of quickbooks integrations automatically pulling money from saved accounts. The Commerce and Logistics domain shouldn't have to care about where the billing domain is saving it's data or how they're getting paid. They just have the responsibility to inform the billing domain when something is sold and when something is shipped.
The Commerce domain likewise shouldn't have to care about how shipping costs are calculated, it just needs to ask the Logistics domain. Commerce shouldn't be rooting around in a database that Logistics needs, becasuse then if Logistics wants to pivot and use google maps to determine shipping costs we'll need to update Commerce then as well.
Once you understand the concept of "Every domain controls it's data, if you need that domains data, you ask that domain." The next bits kinda fall in line.
Each domain will have a Presentation Layer or two, this can be a website, api, mobile/desktop app or a combination of the above. Each domain will have business logic in a domain/application layer. Each domain will be supported by infrastructure like databases and apis.
In the above example we could have a Commerce Domain. It's presentation layer renders a website to a user, it's domain layer is composed of OrderPage and interfaces for commands/queries. It's infrastructure layer has logic to handle those commands and queries, most of them probably go to a private database, but we also have some api calls out to the Logistics and Billing domains.
Our Billing Domain has 2 projects in it's presentation layer. One is an API that's used to field requests from the Commerce and Logistics domains, the other is a desktop app that we wrote for accounting. They both talk to the same domain objects/interfaces so if accounting needs to log in and manually modify an order, they can do so just as easily as if it was happening on the website. The interfaces in the domain are implemented by the infrastructure which could be a quickbooks api which will also forward data into freshbooks until that big migration is finished. No code in Commerce and Logistics has to care about freshbooks/quickbooks, and we can use both at the same time if we want to.
Our Logicstics domain similarly has two projects in it's presentation layer. A console app that runs on a scheduled task once a morning to batch up orders and an api. Same deal with it's data.
Ok that got a bit too long and I'm going to wrap that up. No one will probably read this answer on a 4 year old post anyways lol.
What is the best way to manage users with PirhanaCMS?
I would like to prevent some users from adding content (posts etc...) in some categories and prevent that some sites be listed for some users. (For people who don't know it, PirhanaCMS is a micro CMS programmer oriented).
I would like to use the sites features because I'm working on a project in which I'll have a "network" of several sites managed by different entities of an organization. I would like that each entity be only able to see its own site but that the big organization at the top be able to manage every sites. Moreover, within a site I would like that some users be only able to edit some part of the site.
Are these features built-in ? Otherwise what is the best way to implement them myself around the CMS ?
I am using ASP.NET MVC 4 and EF5.
If you take a look at System > Permissions in the manager area you can see that there are permissions you can give to groups for different parts of the manager interface.
There's however currently no built in support for restricting access to different site trees, but you are free to add a feature request for this at GitHub or maybe participate by implementing it and sending a pull request!
I've searched all over for a possible fit for providing basic commerce functionality (doc'd below) in a white label site, that is dirt simple to admin, and preferably supports auto creation of the site. Super nice to have would be SaaS.
I'm hoping someone has done this before, has a suggestion, or can at least put me out of my misery.
I don't need anything fancy, just a way to light up a vendor site that:
Mandatory:
White Label. This includes any financial components
can connect to a single shared catalog that is shared between many vendors
pick the products they want for their site
Has Social Networking abilities
Nice to Have
has a blog per site (can be a logical
separation)
Has a CMS per site (Can be a logical separation)
Auto creation
Also, SaaS is highly preferred.
The closest I've come is Drupal Commons on the DIY side, but I'd have to see if Commons will work with the existing modules for commerce. Ning is a good example of what I'm trying to do.
DIY, SaaS, whatever, what I really need is some way to provide the above either through process (e.g. Drupal + Aegir) or though a paid service. Custom coding is a last resort for this project.
Take a look at Wordpress 3 multisite with a combination of some plugins from WPMUDev.org... specifically for a basic setup:
Marketpress (Ecommerce) & Supporter (A Pseudo SAAS plugin)
and for good measure i would add some extras like google analytics, WPMU SEO, Mailchimp Integration, ect.
Ive got a pretty complex version of this currently built that i've setup to be easily customizable and i can fork to new "networks/domains" for niche markets and runs on an NGINX server on the Rackspace cloud. Users get subdomains and Every User can map their own domain. Super fast. Super easy to manage and completely able to whitelabel the backend. I develop these types of systems routinely for clients and have reasonable dev rates if you need any help in this area.
I was wondering what's Google's official policy on linking my own websites together, do they forbid it, allow it, allow it as long as it's no-follow, etc.
For clarification i will give both a white-hat and black-hat examples:
white-hat:
I'm a web designer who also has several affiliate websites. I designed those websites so i would like to give myself credit by linking from the affiliate website to my professional bio website where people can hire me as a designer.
black-hat:
I buy 100 different domains and link each one to the other 99 sharing all the link juice between them. The content of each website abide by Google's policy and isn't spammy , the only thing that's wrong is the fact that i got 99 links to each of them and i'm the only one doing the linking.
First solution - nofollow:
Well, if they are nofollow, I don't see why Google would care.
So, you'd probably be safe with that, if what you want to achieve is indeed giving yourself credit.
But, as for SEO optimization, as you already know, the sites wouldn't benefit much.
However with nofollow, even if you didn't increase pagerank, number of visits to each site should increase (the traffic from your other sites). This also could be beneficial.
Second solution - portfolio site:
There is one scenario which could suit your purpose:
Create your "portfolio". A site with links to all the sites you created, as an example of your skills and stuff..
Place a link on each of your sites to this portfolio.
Now, you have a page with 100 outbound links, each perfectly legitimate. And each of your sites contains just one outbound link connecting it to your other sites.
This should be fine both for your presentation and for SEO, and you avoided having a link farm.
EDIT: You can find actual info from Google here: http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf
We are working with an existing SharePoint solution for a Company (its an Intranet). Now, the company is splitting into two and so is their intranet. Each company, of these two, from now on will have their own Intranet. So, idea is to split this Intranet (which is just a web application) into two web applications. But wait, these companies will also have some information to share in between. So, the idea is to put the shared information (Administrative stuff etc) into a separate web application. So, we have three web apps so far.
Previously, Company's intranet was managing the data of about 50 facilities in the form of Subsites. Now, according to new design, each web application will have 25 facilities each. In other words, each company will have 25 facilities. But, problem is that each facility is having large amounts of data almost 5GB+. So, its not possible for me to put the restriction quota at the site level. Although, we can put restriction on the size at SiteCollection level (as per my understanding). So, the idea so far is to create one site collection for each facility, it means we will have 25 site collections in a web applications. Navigation could be a nightmare. But, can we solve navigation problem with managed path etc?
any other suggestions/improvements will be warmly welcome and appreciated! Even your little comment may help me to improve my design ;)
In the proposed design, you will have to manually setup the navigation (managed paths will probably not help unless you want to have something other than /sites/ in the url).
I do question why you now have to split each of the facilities into their own site collection when, before the split, subsites worked. I would only recommend each facility be a unique site collection if you can forsee being asked to move facilities between the two new companies.